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Abstract 

The  United  States  Air  Force  and  many  of  its  Coalition  partners  have  extended 
the  original  service  life  of  some  of  their  aging  aircraft  due  to  fiscal  constraints.  This 
life  extension  often  requires  increased  periodic  and  in-depth  inspections,  increasing 
maintenance  costs  and  resulting  in  longer  periods  of  aircraft  downtime.  An  integrated 
structural  health  monitoring  system  (ISHMS)  for  aging  aircraft  may  reduce  the  cur¬ 
rent  inspection  burden,  and  thus  decrease  costs  and  system  downtime.  This  thesis 
developed  a  generic  systems  engineering  process  to  describe  the  system  definition  for 
an  ISHMS  installed  on  a  non-specific  aging  aircraft.  The  system  definition  developed 
in  this  thesis  followed  the  Vee  Model  for  systems  development  and  serves  as  a  starting 
point  for  future  research  and/or  development  efforts  in  this  field.  User  analysis,  user 
requirements,  system  requirements,  and  some  Department  of  Defense  Architecture 
Framework  system  architectures  formed  the  basis  for  the  generic  systems  engineering 
process  presented.  Furthermore,  mathematical  simulations  compared  the  failure  rate 
and  number  of  inspections  for  a  scenario  without  an  ISHMS  to  a  scenario  with  an 
ISHMS.  This  simplified  analysis  demonstrated  that  a  structural  health  monitoring 
system  for  aging  aircraft  may  have  promising  benefits  with  respect  to  both  safety 
improvements  and  decreased  maintenance  costs. 
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for  Aging  Aircraft 


I.  Introduction 


Figure  1.1:  Chapter  1  Decomposition 


This  chapter  (Figure  1.1)  introduces  the  background  to  the  request  from  the 
Office  of  the  Undersecretary  of  the  Air  Force  for  International  Affairs  (SAF/IA)  to 
develop  a  systems  engineering  (SE)  approach  for  an  integrated  structural  health  mon¬ 
itoring  system  (ISHMS)  for  the  Coalition  Air  Forces’  (CAF)  aging  aircraft.  Chapter  1 
also  addresses  the  problem  statement  and  the  purpose  of  this  thesis.  In  addition,  it 
states  the  reason  this  problem  was  selected  and  briefly  describes  how  this  problem 
was  solved. 

1.1  Background 

The  United  States  Air  Force  (USAF)  and  many  of  its  Coalition  partners  have 
extended  the  original  service  life  of  some  of  their  aging  aircraft  due  to  limited  defense 
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budgets.  However,  this  service-life  extension  often  requires  additional  expensive,  peri¬ 
odic,  and  in-depth  inspections,  resulting  in  the  need  to  ground  aircraft  for  long  periods 
of  time.  The  main  purpose  of  these  inspections  is  to  preserve  safety-of- flight  (SOF), 
with  emphasis  placed  on  maintaining  the  aircrafts’  structural  integrity.  Despite  the 
relative  success  of  these  rigorous  inspections,  the  aging  aircraft  community  is  in  dire 
need  of  a  more  efficient  way  of  monitoring  and  maintaining  the  SOF  of  their  fleet. 
For  example,  the  USAF  has  developed  an  integrated  monitoring  system  on  newer  air¬ 
craft  to  help  screen  the  aircraft’s  structural  health,  allowing  the  required  maintenance 
inspection  criteria  to  be  tailored  to  each  specific  aircraft.  As  a  result,  this  tailored 
inspection  criteria  has  reduced  the  current  inspection  burden,  decreasing  costs,  and 
system  downtime. 

Since  trends  have  revealed  a  pattern  of  operating  military  aircraft  beyond  the 
original  design  life,  there  is  a  distinct  need  for  a  type  of  ISHMS  that  can  be  used 
not  only  on  newer  aircraft  that  have  not  reached  the  end  of  their  service  life,  but 
also  on  aging  aircraft.  “Structural  health  monitoring  refers  to  the  use  of  in-situ, 
non-destructive  sensing  and  analysis  of  structural  characteristics  for  the  purpose  of 
detecting  changes  that  may  indicate  damage  or  degradation  [40].” 

1.2  Thesis  Proposal 

The  CAF  currently  flies  many  of  its  A-37  aircraft  past  the  original  service  life 
and  the  rest  of  the  A-37  fleet  will  soon  exceed  the  service  life.  As  a  result,  the  CAF 
is  experiencing  significant  A-37  aircraft  (Figure  1.2)  downtime  (4-6  months)  due 
to  required  structural  inspections  every  300-flight  hours  [59].  This  situation  was  the 
original  driving  force  behind  the  thesis  proposal  because  the  CAF  A-37  fleet  was 
considered  a  suitable  candidate  for  demonstrating  the  feasibility  of  an  ISHMS  for  an 
aging  aircraft.  Moreover,  the  CAF  has  expressed  interest  in  and  agreed  to  support 
future  efforts  in  this  area. 
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Figure  1.2:  A-37  Photo  [39] 


1.3  Problem  and  Purpose  Statement 

The  problem  the  thesis  team  faced  is  that  a  systems  engineering  approach  has 
not  been  applied  to  the  development  and  implementation  of  a  cost-effective,  near 
real-time,  integrated  structural  health  monitoring  system  on  aircraft  that  did  not 
have  such  a  system  in  place.  The  CAF  needs  this  type  of  system  in  order  to  continue 
the  use  of  their  A-37  aircraft  beyond  the  designed  service  life  while  maintaining  SOF. 

The  purpose  of  this  thesis  is  two- fold.  First,  this  thesis  provides  an  SE  process 
to  help  identify  the  top-level  operational  concept  and  stakeholder  requirements  of  an 
ISHMS  for  a  generic  aging  aircraft.  In  creating  this  SE  process,  the  thesis  team  wore 
two  hats,  that  of  the  user  and  of  the  systems  engineer.  The  methodology  for  the  SE 
process  generally  followed  the  systems  engineering  Vee  Model  (Figure  1.3).  The  thesis 
team  created  baseline  products  to  perform  the  initial  iteration  of  system  definition 
and  composition,  up  to,  but  not  including,  preliminary  design. 

Second,  this  thesis  performed  a  preliminary  analysis  to  demonstrate  the  poten¬ 
tial  benefit  of  developing  an  ISHMS  for  aging  aircraft,  using  the  A-37  aircraft  as  an 
example.  Basically,  the  calculations  presented  in  this  thesis  are  meant  to  provide 
rough  estimates  that  could  be  used  to  support  a  financial  decision  for  funding  the  de¬ 
velopment  of  an  ISHMS,  based  on  several  assumptions  that  will  be  explained  in  future 
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Figure  1.3:  Vee  Model  [17] 


chapters.  Using  material  analysis  and  crack  growth  modeling,  simplified  simulations 
were  created  to  compare  the  benefits  of  utilizing  an  ISHMS  on  aging  aircraft  to  the 
status  quo  of  flying  without  an  ISHMS  installed.  The  potential  benefit  of  an  ISHMS 
was  determined  from  both  the  safety  and  cost  perspectives.  Cost  savings  achieved 
from  reduced  maintenance  inspections  constrain  the  maximum  limit  of  the  ISHMS 
development,  procurement,  and  installation  costs.  From  a  purely  cost  standpoint  the 
ISHMS  would  not  be  beneficial  if  its  life-cycle  costs  exceeded  the  cost  savings  it  pro¬ 
vided.  Any  additional  positive  and  negative  effects  beyond  the  maintenance  realm 
were  also  considered.  For  example,  if  an  ISHMS  limited  the  aircraft  performance 
significantly  enough  to  degrade  aircraft  mission  effectiveness,  then  the  ISHMS  would 
not  be  beneficial,  even  if  the  maintenance  costs  savings  were  favorable. 

This  thesis  is  organized  in  an  attempt  to  walk  you  through  the  various  steps  from 
identifying  the  problem  to  recommending  further  research  areas  to  solve  the  problem. 
The  next  chapter,  Chapter  2,  provides  a  more  detailed  description  of  the  background 
associated  with  the  problem  and  summarizes  the  findings  of  the  relevant  literature 
pertaining  to  the  problem  and  its  background.  The  team  decided  to  concentrate  on 
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the  development  of  an  SE  approach  to  an  ISHMS.  Chapter  3  explains  the  scope, 
or  boundaries,  of  the  problem  and  the  methodology  used  to  solve  it.  The  results 
of  implementing  the  methodology  are  presented  in  Chapter  4.  Finally,  Chapter  5 
declares  the  conclusions  drawn  from  this  study  and  provides  recommendations  for 
further  research  in  this  problem  area. 
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II.  Aging  Aircraft  and  Structural  Health  Background 


Figure  2.1:  Chapter  2  Decomposition 

This  chapter  (Figure  2.1)  provides  the  background  on  the  problem  of  aging  air¬ 
craft  and  structural  health.  The  chapter  begins  with  a  look  at  aircraft  structural 
failures  and  how  flight  safety  is  determined,  specifically  with  respect  to  aircraft  struc¬ 
tural  failure.  Next,  it  contains  a  review  of  aging  aircraft  and  the  associated  issues  and 
problems.  This  leads  to  a  summary  of  structural  health  monitoring  implementations 
to-date  and  an  examination  of  solutions  to  maintaining  the  safety  of  aging  fleets  with 
limited  budgets.  The  chapter  then  provides  a  more  detailed  review  of  the  issues  as¬ 
sociated  with  the  aging  A-37  and  T-37  aircraft.  Finally,  a  summary  of  the  systems 
engineering  process  is  presented. 
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2.1  Aircraft  Structural  Failures 

Structural  failure  occurs  when  a  structure  breaks  in  such  a  way  that  it  can 
no  longer  carry  as  much  load  as  it  could  before  the  failure  [2],  A  failure  of  any 
aircraft  structure  can  be  catastrophic.  Aircraft  structural  failures  usually  result  from 
design  and  manufacture  flaws,  maintenance  damage,  or  damage  occurring  during 
operational  use.  Structural  damage  resulting  from  maintenance  actions  is  rare.  In 
fact,  operational  use  exacerbating  an  existing  flaw  from  design  or  manufacture  is 
most  often  the  reason  for  aircraft  structural  failure.  A  complete  understanding  of 
aircraft  structural  failure  phenomenon  enables  engineers,  maintainers,  and  other  key 
personnel  to  correct  or  mitigate  problems  before  structural  failure  occurs. 

While  rare,  maintenance  personnel  can  cause  damage  to  aircraft  structures  in 
innumerable  ways.  Maintainers  may  perform  improper  maintenance,  using  the  in¬ 
correct  maintenance  practices,  and  wrong  materials,  parts,  or  tools.  These  foreign 
parts  or  materials  may  not  perform  as  required  and  can  cause  damage  to  neighboring 
structural  elements  that  may  see  increased  loads  as  a  result.  When  reassembling  the 
aircraft,  maintainers  cannot  assemble  the  aircraft  back  to  its  precise  configuration 
prior  to  disassembly.  This  change  in  aircraft  structural  configuration  can  change  load 
paths  on  structural  elements.  The  mere  act  of  walking,  leaning,  or  sitting  on  struc¬ 
tural  members  may  impart  a  load  on  a  structural  element  not  seen  during  operational 
use.  Maintenance  is  critical  to  the  aircraft,  and  aircraft  maintainers  are  skilled,  tal¬ 
ented  individuals.  As  stated,  rarely  will  maintainers  cause  any  significant  structural 
damage  to  an  aircraft;  however,  the  possibility  exists  and  must  be  considered. 

The  type  of  damage  that  causes  structural  failure  usually  is  born  during  the 
design  or  manufacturing  stage.  Similar  to  maintainers,  the  aircraft  manufacturing 
technician  may  unknowingly  introduce  damage  to  an  aircraft.  Again  while  rare,  tech¬ 
nicians  may  not  assemble  exactly  to  the  design  and  introduce  unintended  loads.  Air¬ 
craft  designers  can  also  introduce  flaws  through  poor  design  and  poor  selection  of 
materials.  Even  if  a  person  could  discount  maintenance,  all  materials  have  internal 
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flaws  due  to  design  and  manufacturing  induced  flaws,  that  are  not  perceptible  during 
manufacture  and  contribute  to  variability  in  material  strength,  ft  can  be  generally 
assumed  that  these  material  flaws  exist  in  all  new  aircraft,  and  these  flaws  will  even¬ 
tually  become  cracks.  These  imperceptible  flaws  will  most  likely  be  the  eventual  root 
cause  of  structural  failure  when  exposed  to  the  punishment  of  aircraft  operations. 

Operational  use  is  the  main  cause  of  structural  damage.  Occasionally,  in-flight 
damage  such  as  bird  strikes  can  contribute  to  structural  damage.  However,  the  main 
causes  of  structural  damage  and,  ultimately,  failure  are  the  repeated  loading  and 
cycling  that  occurs  on  the  structure  from  takeoffs,  landings,  flight  maneuvers  and 
aircraft  weapons  and  g-loads.  The  severity  and  frequency  of  the  loading  and  cycling 
directly  correlate  with  how  quickly  and  to  what  degree  structural  damage  occurs. 
Today,  the  operational  use  of  many  aircraft  exceeds  that  for  which  it  was  originally 
designed.  This  translates  to  quicker  and  more  rampant  structural  damage  than  was 
estimated  during  design. 

The  most  probable  locations  for  structural  damage  resulting  from  operational 
use  are  known  as  fatigue  critical  locations  (FCL).  FCLs  are  where  local  stresses  are 
usually  highest.  Fatigue  critical  locations  can  also  result  from  a  particular  structural 
element’s  material  or  design  that  makes  it  more  susceptible  to  fatigue.  Examples  of 
common  FCLs  are  joints,  rivet  holes,  and  bolt  holes. 

Corrosion  and  fatigue  represent  the  two  highest  concerns  regarding  structural 
damage.  Corrosion  only  occurs  during  operational  use.  Fatigue,  as  mentioned,  is 
an  exacerbation,  during  operational  use,  of  a  previous  condition.  While  corrosion  is 
theoretically  preventable,  fatigue  is  not.  Fatigue  will  eventually  lead  to  structural 
failure.  When  failure  occurs  depends  on  the  number  of  inherent  flaws,  the  location  of 
the  flaws  in  the  aircraft,  and  the  severity  of  operational  use. 

Typically,  corrosion  alone  is  not  a  cause  for  structural  failure.  Corrosion  is 
inspected  for  during  maintenance  and  removed  or  structures  are  replaced  wherever 
found.  Detection  inside  the  aircraft  is  usually  limited  to  visual  means;  therefore, 


corrosion  may  not  be  discovered  on  some  structural  elements.  This  undiscovered  cor¬ 
rosion  can  cause  a  significantly  decreased  damage  tolerance  in  a  structural  element. 
For  instance,  if  a  crack  were  to  propagate  in  a  corroded  structural  element,  the  com¬ 
bination  of  the  crack  and  corrosion  would  decrease  the  elements  strength  greater  than 
either  one  alone. 

Structural  fatigue  resulting  from  repetitive  operational  use  is  the  primary  cause 
of  structural  failure.  For  example,  aluminum,  a  type  of  material  used  in  aircraft 
design,  does  not  have  an  endurance  limit;  therefore,  it  accumulates  damage  with 
use.  Use  generates  fatigue,  so  to  avoid  fatigue  would  mean  to  avoid  use.  This  is  not 
practical,  thus  fatigue  is  not  preventable.  Fatigue  must  be  understood  and  monitored 
to  mitigate  the  potential  catastrophic  effects. 

Fatigue  generally  results  from  two  types  of  loading:  low  cycle  and  high  cycle. 
Flight  maneuvering  and  aircraft  loading  generate  low-cycle  fatigue.  Low-cycle  fatigue 
usually  has  a  higher  amplitude  and  lower  frequency  than  high-cycle  fatigue.  Vibration 
from  aerodynamic,  mechanical,  or  acoustic  sources  leads  to  high-cycle  fatigue.  The 
loads  generated  from  flight  maneuvering  and  aircraft  loading  can  be  estimated  quite 
well  during  aircraft  design.  These  estimations  remain  quite  accurate  as  long  as  the 
aircraft  operates  within  the  original  design  parameters  for  operational  use.  In  contrast, 
the  high-cycle  loads  can  also  be  estimated  during  aircraft  design,  but  these  loads  will 
most  probably  change  later  in  the  aircraft’s  life.  This  phenomenon  occurs  due  to 
changes  in  the  response  of  the  structure  due  to  wear,  repairs,  structural  cracks  or 
variations  in  operational  use  or  aircraft  configuration. 

Cracking  is  a  result  of  fatigue.  Since  cracking  can  not  be  prevented,  it  needs  to 
be  precisely  predicted  such  that  aircraft  safety  can  be  maintained.  Crack  prediction 
encompasses  timing  of  crack  initiation  and  crack  growth  speed.  Progress  has  been 
made  in  the  areas  of  crack  initiation  and  small-crack  growth,  but  predictive  mod¬ 
eling  of  these  phenomenons  still  eludes  the  scientific  community  [61].  If  initiation 
and  growth  are  accurately  predicted,  timing  of  critical  crack  length  can  be  predicted. 
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Critical  length  is  defined  as  the  crack  length  that  will  cause  structural  failure  of  the 
fatigued  element.  This  assumes  a  single  crack  in  an  element.  Widespread  fatigue 
damage  (WFD)  complicates  the  problem  further.  The  existence  of  multiple  cracks 
of  sufficient  size  and  density  to  decrease  strength  is  WFD.  The  multiple  cracks  may 
occur  in  the  same  structural  element  or  adjacent  structural  elements.  Whenever  and 
however  cracking  occurs,  the  more  accurately  it  can  be  predicted  and  the  effects  on 
structural  strength  analyzed;  the  longer  aircraft  can  be  safely  flown  prior  to  mainte¬ 
nance  action  or  aircraft  retirement.  [61] 

Cracking  is  such  a  critical  safety  issue  that  aircraft  designers  account  for  its 
occurrence  during  design.  Typically,  aircraft  designers  account  for  structural  cracks 
through  two  design  approaches,  safe  crack  growth  design  and  fail-safe  design.  Safe 
crack  growth  is  typically  used  for  high-performance  combat  aircraft  where  weight  is 
a  considerable  consideration.  Safe  crack  growth  design  ensures  that  the  maximum 
probable  undetectable  initial  manufacturing  flaw  will  not  grow  to  critical  size  in  any 
critical  structure  during  the  operational  life  of  the  aircraft.  This  requires  a  consider¬ 
able  engineering  analysis  using  crack  growth  prediction  models.  Since  the  prediction 
models  are  not  precise,  a  large  safety  factor  is  introduced.  Additionally,  concerns 
exist  with  not  accounting  for  all  possible  FCLs  in  the  original  analysis.  Other  loca¬ 
tions  may  also  become  critical  in  aging  aircraft.  Fail-safe  design  relies  on  multiple, 
redundant  load  paths  or  crack  arrest  features  to  mitigate  the  effects  of  cracks.  This 
design  approach  is  typically  used  in  larger  aircraft. 

Understanding  aircraft  structural  failures  and  their  causes  is  a  complex  problem. 
While  work  is  still  being  done,  predictive  models  are  not  always  accurate.  Detection 
of  structural  damage  can  be  difficult.  Overall,  structural  integrity  issues  for  aging 
aircraft  are  particularly  difficult  because  the  damage  under  consideration  consists  of 
multiple  interacting  flaws  and  the  crack  sizes  are  often  in  a  range  where  the  phe¬ 
nomenon  is  complex  and  not  well  behaved  [61]. 
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2.2  Flight  Safety 


Aircraft  in-flight  safety  is  critical.  Obviously,  a  critical  failure  occurring  dur¬ 
ing  flight  affects  flight  itself,  and  thus  could  spell  catastrophic  consequences  for  the 
aircraft,  its  crew,  passengers,  and  cargo.  As  such,  a  balance  is  struck  between  the 
accepted  risk  of  critical  failure  and  aircraft  life.  The  accepted  risk  and  aircraft  life 
calculations  have  varied  over  time  and  still  vary  among  different  aircraft  users,  man¬ 
ufacturers,  and  stakeholders  today.  Often,  the  estimated  aircraft  life  is  based  on  a 
very  low  level  of  probability  of  failure  along  with  a  high  safety  factor  to  account  for 
variability. 

The  aircraft’s  life  is  calculated  at  several  different  intervals  of  time.  When  an 
aircraft  is  first  designed,  a  preliminary  calculation  sets  the  design  life.  This  design 
life  is  based  on  the  expected  flight  profiles  the  aircraft  will  operate  within,  such  as, 
maximum  g-loading,  maximum  flight  speed,  average  flight  speed,  number  of  takeoffs 
and  landings,  average  flight  altitude,  static  loads  within  the  aircraft  body  such  as 
passengers  and  cargo,  or  any  loads  carried  on  the  wings.  The  calculations  translate 
the  flight  loads  down  to  local  stresses  on  structural  elements.  Based  on  the  expected 
stresses  over  time,  estimations  are  made  on  how  long,  often  expressed  in  flight  hours, 
the  highest  stressed  elements  will  last  before  critical  failure.  Typically,  the  safe  life  is 
calculated  as  the  design  life.  The  safe  life  is  defined  as  the  estimated  mean  fatigue  life 
of  the  aircraft  structure  divided  by  a  scatter  factor  [65].  The  scatter  factor  ensures 
the  probability  of  failure  is  low.  To  maintain  a  high  degree  of  confidence  in  this  life 
estimation,  inspections  are  often  performed  on  the  structural  elements  that  form  the 
basis  for  the  design  life,  or  the  FCLs.  If  the  inspections  find  damage  occurring  before 
the  expected  timeframe,  those  structural  elements  may  be  replaced  or  redesigned. 
This  modification  along  with  general  aircraft  maintenance  will  affect  the  original 
design  life,  often  extending  the  life.  Additionally,  inspections  can  be  accomplished  to 
verify  that  the  original  design  estimations  regarding  damage  were  accurate.  This  can 
be  quite  challenging.  Even  when  actual  historical  damage  data  is  gathered,  further 
crack  growth  and  critical  crack  length  must  be  estimated. 
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In  general,  the  safe-life  estimation  led  to  aircraft  being  retired  long  before  their 
time.  For  example,  if  the  accepted  cumulative  probability  of  failure  was  99.9%  over 
the  life  of  the  aircraft,  then  for  a  fleet  of  one  thousand  aircraft,  999  were  being 
retired  still  having  some  useful  life.  This  dilemma  led  to  the  fail-safe  philosophy 
where  a  planned  inspection  process  was  spelled  out.  Aircraft  were  allowed  to  continue 
flying  until  damage  discovered  from  planned  inspections  was  enough  to  retire  the 
aircraft.  This  philosophy  spawned  the  Aircraft  Structural  Integrity  Program  (ASIP). 
The  ASIP  detailed  the  required  inspections  for  varying  aircraft.  The  ASIP  also  worked 
to  determine  residual  strength  of  structural  elements  given  crack  growth.  It  was  during 
this  time  non-destructive  inspection  (NDI)  techniques  became  even  more  important. 
Since  the  fail-safe  philosophy  was  attempting  to  push  the  envelope  on  aircraft  life, 
the  inspections,  this  philosophy  required,  needed  to  be  able  to  detect  as  much  of  the 
relevant  structural  damage  as  possible.  [65] 

Eventually,  the  fail-safe  philosophy  was  abandoned  under  the  ASIP  and  the 
damage  tolerance  philosophy  was  adopted.  The  damage  tolerance  philosophy  works 
much  like  the  fail-safe;  however,  it  puts  more  of  a  focus  on  understanding  opera¬ 
tional  stresses  and  loads  and  how  they  affect  crack  growth  and  structural  fatigue. 
This  was  beneficial  because  many  aircraft  users  were  exceeding  the  original  operat¬ 
ing  parameters  and  the  older  methods  did  not  consider  this  change  would  not  be  as 
accurate.  Damage  tolerance  assessments  considered  the  different  cycling  loads,  differ¬ 
ent  aircraft  designs,  and  high-cycle  and  low-cycle  fatigue.  As  such,  different  classes 
of  aircraft  required  different  damage  tolerance  methodologies.  Overall,  the  damage 
tolerance  approach  calculates  crack  growth  deterministically  using  constant  material 
properties  and  a  known  initial  flaw  size.  This  deterministic  approach  to  the  stochas¬ 
tic  problem  of  structural  damage  has  led  to  new  approaches  being  developed  and 
analyzed  today.  [65] 

The  probabilistic  approach  had  been  born  to  address  the  stochastic  nature  of 
crack  development  and  growth  and  variability  in  material  properties.  Additionally, 
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the  probabilistic  approach  may  be  able  to  safely  extract  more  life  from  an  aircraft  in 
today’s  times  of  reduced  budgets. 

Today,  the  life  of  an  aircraft  fleet  is  no  longer  governed  by  its  original  design 
life.  To  a  great  extent,  the  life  is  determined  by  the  mission  need,  the  maintenance 
cost,  and  the  economic  considerations  required  for  the  fleet  to  continue  its  operational 
requirements  [65]. 

2.3  Aging  Aircraft  Trends 

Structural  health  concerns  are  focused  on  aircraft  with  increasing  age.  Civilian 
and  military  aircraft  inventories  have  both  experienced  a  gradual  and  continual  in¬ 
crease  in  the  average  aircraft  age.  In  the  civilian  general  aviation  market,  the  high 
cost  of  new  aircraft  reduced  new  aircraft  purchases  resulting  in  legacy  aircraft  usage 
beyond  the  original  design  service  life  (Figure  2.2). 

Civilian  commercial  and  general  aviation  aircraft  inventories  have  both  increased 
in  average  aircraft  age.  The  high  cost  of  new  aircraft  forced  the  civilian  general 
aviation  market  to  purchase  and  maintain  legacy  aircraft  beyond  the  original  design 
service  life  (Figure  2.3). 

Similarly,  the  high  cost  of  Operations  and  Maintenance  (O&M)  of  legacy  mili¬ 
tary  aircraft  combined  with  the  high  cost  of  new  aircraft  purchase  created  an  aging 
military  aircraft  fleet.  This  trend  showed  that  the  United  States  was  imable  to  pur¬ 
chase  enough  new  aircraft  each  year  to  reduce  average  aircraft  age.  This  inability  to 
reduce  the  average  age  of  the  United  States  military  aircraft  has  been  coined  a  “death 
spiral”  by  the  Joint  Council  on  Aging  Aircraft  (JCAA).  The  “death  spiral”  started 
with  deferring  modernization  and  recapitalization  due  to  constrained  resources.  This 
resulted  in  the  further  increasing  the  age  of  weapon  systems  with  an  associated  in¬ 
crease  in  maintenance.  This  increased  maintenance  drove  up  O&M  costs  and  reduced 
readiness,  which  then  required  the  shifting  of  funds  from  procurement  accounts  to 
O&M  to  keep  our  existing  systems  mission  capable.  The  Congressional  Budget  Office 
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Year 


Figure  2.2:  General  Aviation  Aircraft  Manufactured  [33] 


Figure  2.3:  Number  of  Aircraft  vs.  Age  [22] 
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(CBO)  estimated  “spending  on  O&M  for  aircraft  increases  by  1  percent  to  3  percent 
for  every  additional  year  of  age,  after  adjusting  for  inflation”  [43].  These  market  forces 
created  an  increase  in  the  average  age  of  military  aircraft  (Figure  2.4). 


Figure  2.4:  Average  Fleet  Age  [42] 


One  of  the  reasons  average  aircraft  ages  were  increasing  was  the  high  cost  of 
purchasing  new  aircraft.  The  civilian  general  aviation  industry  incurred  a  large  cost 
risk  from  future  aircraft  liability  litigation  as  well  as  regulatory  cost  of  compliance. 
The  high  cost  of  future  legal  defense,  settlements,  and  regulatory  compliance  nega¬ 
tively  impacted  the  ability  to  produce  general  aviation  aircraft  at  a  low  cost.  The 
Manufacturers  Alliance  (MAPI)  estimated  90%  of  aircraft  fatalities  resulted  in  a  law¬ 
suit  of  the  aircraft  manufacturer,  even  though  historically  85%  of  crashes  were  the 
result  of  pilot  error  [52] .  The  rising  cost  of  litigation  parallelled  the  increase  in  lawyer 
supply  as  well  as  a  reduction  in  the  burden  of  proof  in  aircraft  liability  cases.  The 
increasing  numbers  of  lawyers  (Figure  2.5)  versus  the  number  of  United  States  citi¬ 
zens  coincides  with  the  California  Supreme  Court  initiated  change  in  product  liability 
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laws  in  the  1960’s  to  the  1970’s.  The  product  liability  laws  changed  to  the  precept 
of  strict  liability  decreasing  the  burden  of  proof  from  having  to  show  negligence  to 
only  having  to  show  a  product  defective.  In  1978,  “manufacturers  of  private  aircraft 
faced  liability  insurance  expenses  amounting  to  an  average  of  $100,000  per  aircraft 
produced”  [53].  This  concept  of  strict  liability  spread  throughout  the  United  States 
court  system  in  the  1970’s  to  the  1980’s  and,  coupled  with  the  increasing  lawyer  ca¬ 
pacity,  was  widely  blamed  for  the  rise  in  the  cost  of  general  aviation  aircraft  and  the 
demise  of  the  general  aviation  industry. 


Figure  2.5:  US  Population  vs  Lawyer  Population  Growth  [8] 


The  legal  costs  of  the  aviation  industry  worsened  with  increasing  aircraft  age. 
Aircraft  operating  beyond  original  service  life  created  a  series  of  accidents  and  in¬ 
cidents  spurring  Congress  to  mandate  new  regulations.  The  increase  in  regulations 
increased  the  cost  of  regulatory  compliance.  New  regulations  enacted  by  Congress 
occurred  in  waves  after  high  profile  aircraft  accidents/incidents.  One  example  of  a 
high  visibility  structural  failure  was  that  of  the  1988  Aloha  in-flight  decompression. 
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The  fatigue  failure  of  an  Aloha  Airlines  Boeing  737  on  April  28,  1988  (Figure  2.6) 
resulted  in  Congress  passing  the  Aviation  Safety  Research  Act  of  1988. 


Figure  2.6:  Boeing  737-200  Catastrophic  Failure  [37] 


The  Federal  Aviation  Administration  (FAA)  responded  to  the  Aviation  Safety 
Research  Act  and  concerns  related  to  the  increasing  age  of  aircraft  fleets  by  developing 
the  National  Aging  Aircraft  Research  Program  (NAARP).  The  purpose  of  NAARP 
was  to  ensure  the  structural  integrity  of  high-time,  high-cycle  aircraft.  The  NAARP 
cornerstone  was  the  development  of  commuter  aircraft  supplemental  structural  in¬ 
spections.  The  supplemental  structural  inspections  were  required  by  Supplemental 
Inspection  Documents  (SID).  These  inspections  were  required  for  large  aging  trans¬ 
port  aircraft  starting  in  the  1980’s  and  have  successfully  ensured  the  structural  in¬ 
tegrity  of  these  aircraft.  From  1980-1990,  initiatives  were  created  to  extend  this  SID 
process  to  conduct  damage  tolerance  assessments  on  the  airframes  of  small  aging  com¬ 
muter  aircraft.  While  the  Aviation  Safety  Research  Act  of  1988  was  successful,  each 
new  wave  of  legislation  increased  the  regulatory  burden  placed  upon  the  aviation  in¬ 
dustry.  Increasing  the  regulatory  burden  increases  the  cost  of  compliance,  and  results 
in  a  higher  cost  of  new  aircraft.  The  regulations  impacting  the  cost  of  new  aircraft  in- 
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elude:  The  1946  Federal  Tort  Claims  Act  which  allows  cases  to  be  brought  against  the 
federal  government  for  the  negligence  of  air  traffic  controllers,  but  limits  liability  of 
military  members  (or  survivors)  to  bring  suit  against  the  government.  The  1958  Fed¬ 
eral  Aviation  Act  and  Regulations  which  established  the  FAA  and  set  minimum  safety 
standards  for  flight  operations  and  aircraft  manufacture.  The  1976  Foreign  Sovereign 
Immunities  Act  defined  foreign  states  and  limits  suits  against  foreign  governments  and 
foreign  aircraft  industries.  Most  importantly  states  dictate  applicable  law  (i.e. ,  prod¬ 
uct  liability  rules).  Additionally,  the  cost  of  litigation  is  heavily  influenced  by  state 
and  federal  laws;  personal  injury  and  wrongful  death  damage  standards,  “tort  reform” 
(limitations  on  recovery)  measures,  military  contractor  defense  (limits  manufacturer 
liability),  and  workers’  compensation  (limits  the  employer  liability).  The  regulatory 
cost  of  compliance  in  the  aviation  industry  is  ever  increasing.  The  1996  Aviation  Dis¬ 
aster  Family  Assistance  Act  required  that  airlines  must  offer  crisis  counseling,  make 
hotel  rooms  and  food  available,  help  family  members  retrieve  dental  records  and  X- 
rays  to  identify  the  victims,  provide  transportation  to  and  from  the  crash  site,  and 
airlines  should  even  consult  family  members  about  a  memorial.  Increased  litigation 
and  regulation  created  an  increased  financial  risk  for  general  aviation  industries.  This 
increased  risk  created  an  increased  cost  to  mitigate  the  risk  and  resulted  in  an  ever 
increasing  cost  of  aircraft  (Figure  2.7).  The  increasing  cost  of  general  aviation  aircraft 
reduced  the  market  demand  and  resulted  in  many  general  aviation  aircraft  builders 
going  out  of  business.  [33] 

In  1994,  Congress  moved  to  mitigate  the  external  impact  of  increased  litigation 
on  the  general  aviation  industry.  The  United  States  Congress  passed  the  General 
Aviation  Revitalization  Act  (GARA),  which  limited  the  liability  of  an  aircraft  manu¬ 
facturer  to  18  years  after  aircraft  delivery.  While  this  change  in  the  legal  system  saved 
the  last  few  aircraft  manufacturers,  the  number  of  general  aviation  aircraft  manufac¬ 
turers  and  aircraft  manufactured  had  dwindled  (Figure  2.8).  The  contraction  in  the 
number  of  general  aviation  aircraft  manufacturers  reduced  the  free  market  ability  to 
keep  aircraft  prices  down  through  open  competition. 
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Figure  2.7:  Cessna  172  Price  vs  Time  [22] 
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Figure  2.8:  United  States  Aircraft  Production  [21] 
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A  series  of  external  liability  and  regulatory  factors  increased  the  cost  of  manu¬ 
facturing  an  aircraft.  This  increase  in  new  aircraft  cost  led  many  countries  to  conduct 
a  series  of  structural  life  extension  programs  to  maximize  service  life  of  aircraft  in  their 
inventory.  The  systematic  process  of  extending  aircraft  service  life  coupled  with  low 
numbers  of  new  aircraft  purchased  created  an  overall  increase  in  the  average  aircraft 
age  of  both  military  and  civilian  aircraft. 

The  result  of  the  increasing  age  of  civilian  and  military  aircraft  can  be  broadly 
categorized  into  increased  downtime  for  large  inspections  and  increased  cost  of  inspec¬ 
tions  and  repairs.  Additionally,  there  is  a  hard-to-quantify  effect  on  aircraft  safety 
as  fatigue  and  environmental  factors  effects  become  wide-spread  issues.  Currently, 
the  National  Transportation  and  Safety  Board  (NTSB)  show  only  a  small  percentage 
(~10%)  of  aircraft  accidents  are  caused  by  structural  failures  (Figure  2.9). 

The  potential  for  increased  failures  is  caused  by  the  aircraft  age  magnifying  the 
effects  caused  by:  additive  damage  of  improper  usage,  the  compounding  effects  of 
limited/improper  maintenance,  limitations  in  design  beyond  the  original  service  life, 
unforeseen  material  selection  interactions  (stress  corrosion  cracking),  material  im¬ 
perfections  becoming  stress  concentrations  for  fatigue  critical  locations,  replacement 
parts  substandard  micro  structures/crystal  structure/grain  size/ microvoids  caused  by 
material  impurity  or  heat  treatment /processing  deficiency.  Additionally,  early  fabri¬ 
cation  errors  may  be  lurking  time-bombs  with  assembly  error,  machining  error  (stress 
concentrations),  welding  heat  treatment  effects  interacting  with  fatigue  conditions, 
creep,  and  combined  loading. 

2.f  Evolution  of  Health  Monitoring  Systems 

In  recent  years,  there  has  been  an  increasing  effort  in  the  aerospace  domain 
for  the  development  of  structural  health  monitoring  systems  for  aircraft  and  aircraft 
components.  Aerospace  manufacturers  and  numerous  institutions  around  the  world 
have  been  working  in  this  area  and  their  research  has  been  moving  in  many  directions. 
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Top  Causes/Factors  in  Part  121  Accidents  for  2000 
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*  Broad  causes/faciors  were  available  in  52  of  56  Part  121  accidents. 

**  “Others  {not  aboard)''  refers  to  33  different  parties,  including  air  traffic  control  personnel, 
manufacturers,  ground  personnel,  and  FAA  personnel. 


Figure  2.9:  Aircraft  Failure  Causes  [51] 


21 


The  traditional  approach  of  aircraft  maintenance  is  to  conduct  inspections  peri¬ 
odically  based  on  a  schedule.  During  the  system’s  design  a  number  of  critical  locations 
are  identified  and  a  maintenance  schedule  is  developed  with  the  purpose  of  inspecting 
these  locations.  As  the  system  goes  into  service,  the  periodic  inspection  schedule  is 
reevaluated  and  new  areas  requiring  inspection  may  be  identified,  or  the  inspection 
frequency  for  some  other  areas  may  be  modified. 

The  periodic  scheduled  inspections  are  performed  for  some  critical  areas  and  se¬ 
lected  components  of  the  aircraft,  while  other  areas  and  difficult  to  reach  components 
are  being  inspected  less  frequently  or  whenever  access  to  them  is  gained  due  to  other 
maintenance  actions. 

Approximately  90%  of  these  conventional  inspections  [13]  are  visual  inspections 
and  most  of  the  remaining  percentage  are  NDI.  The  visual  inspections  consist  of 
intensive  checks  using  inspection  aids  (such  as  mirrors,  lenses,  etc)  and  require  the 
involvement  of  the  maintenance  technicians.  During  these  inspections,  the  technicians 
are  trying  to  identify  structural  irregularities  before  they  become  critical  and  their 
results  sometimes  depend  on  the  technician’s  ability  to  access  the  inspected  area  and 
to  correctly  assess  its  condition. 

The  NDI  and  Non-Destructive  Evaluation  (NDE)  techniques  consist  of  some  of 
the  following: 

•  ultrasound  inspections,  eddy  currents 

•  Magnetic  Particle  Inspections 

•  Fluorescent  Penetrate  Inspections 

•  x-ray  inspections 

These  techniques  provide  some  level  of  automation  of  the  inspection  procedure 
comparing  to  the  visual  inspections.  A  basic  limitation  of  these  methods  is  that 
these  techniques  can  only  inspect  and  detect  specific  types  of  flaws.  Ultrasounds, 
for  example,  are  efficient  in  detecting  corrosion  and  flaws  in  composites  and  surfaces; 
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Eddy  currents  are  efficient  for  fatigue  cracking  detection.  Also,  these  methods  are 
generally  customized  to  inspect  a  specified  area  (e.g.  different  ultrasound  probes 
are  developed  to  inspect  different  areas).  Some  NDE  inspections  may  be  performed 
once  while  some  others  may  require  extensive  preparation  and/or  significant  system 
downtime.  Although  these  inspections  can  be  more  effective  than  conventional  visual 
inspections,  they  only  provide  a  snapshot  of  the  inspected  area  at  the  time  of  the 
inspection. 

According  to  the  traditional  approach,  aircraft  maintenance  is  based  on  record¬ 
ing  and  monitoring  parameters  such  as  flight  hours,  mission  type  and  duration,  aircraft 
configuration  flown,  etc.  These  parameters  are  used  to  schedule  the  maintenance  for 
each  individual  aircraft  and  also  to  manage  the  total  fleet.  A  basic  assumption  is  that 
fleet  average  parameters  match  those  of  the  individual  aircraft. 

As  the  experience  and  knowledge  on  aircraft  use  and  maintenance  practices 
increased  worldwide,  it  became  understood  that  each  aircraft  operator  has  a  different 
system  usage.  There  is  different  usage  of  each  individual  aircraft  in  the  same  fleet  and 
that  the  approach  of  conducting  maintenance  based  on  fleet  wide  average  parameters 
is  not  accurate  enough.  Especially,  the  operators  of  military  aircraft  (fighter,  trainer, 
attack  aircraft)  realized  that  there  is  substantial  variability  in  their  usage  profiles  and 
that  their  aircraft  cannot  be  tracked  based  only  administrative  parameters  such  as 
flight  hours.  Also,  the  operators  realized  that  the  actual  usage  loading  on  their  systems 
was  more  severe  than  that  predicted  from  the  design  models.  More  accurate  methods 
for  aircraft  systems  management  were  developed  but  there  is  still  a  large  variability 
among  the  different  operators.  As  a  result  of  this  understanding,  the  concept  of  a 
fatigue  management  program  and  the  idea  of  a  Structural  Health  Monitoring  System 
(SHMS)  have  emerged. 

2-4-1  Fatigue  Management  Programs.  Fatigue  management  program  follows 
an  integrated  plan  comprising  of  4  factors  [7].  These  4  factors  are  the  fatigue  manage¬ 
ment  process,  an  individual  aircraft  tracking  program,  a  fatigue  monitoring  system, 
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and  the  calibration  of  fleet  results.  The  fatigue  management  process  starts  during  the 
design  of  the  system  and  continues  during  the  system’s  operational  life  with  fatigue 
monitoring,  which  is  the  process  of  collecting  operational  loading  data.  The  reason 
for  performing  fatigue  monitoring  is  to  record  the  actual  operational  loading  history 
of  the  aircraft,  to  ensure  that  the  aircraft  is  not  operated  beyond  an  acceptable  risk 
level,  and  to  ensure  that  the  aircraft  will  survive  at  least  throughout  its  design  life 
under  normal  operating  conditions.  As  part  of  the  fatigue  management  program,  the 
collected  loading  data  is  used  in  order  to  improve  the  systems  structural  integrity. 

The  first  fatigue  management  programs  were  mainly  centered  around  load  mon¬ 
itoring.  The  reason  is  that  operational  loads  are  an  essential  parameter  for  describing 
the  aircraft  usage  and  predicting  the  system’s  residual  life.  The  loads  were  monitored 
by  using  strain  gauges  installed  at  various  points  on  the  aircraft  or  by  recording  flight 
parameters  and  calculating  (using  mathematical  models)  the  resulting  loads  for  the 
critical  locations.  The  main  advantages  of  this  approach  are  that  it  allows  the  actual 
usage  to  be  determined,  it  helps  the  user  operate  the  aircraft  accordingly,  and  it  allows 
the  residual  life  of  the  system  to  be  fairly  accurately  estimated.  This  approach  for 
conducting  fatigue  management  guarantees  the  safe-life  performance  of  the  aircraft 
and  is  very  popular  among  the  operators  of  military  aircraft. 

The  more  current  approach  for  managing  the  fatigue  on  an  aircraft  is  by  damage 
monitoring.  Fatigue  management  programs  based  on  this  approach  are  still  in  the 
development  stage.  This  type  of  program  tries  to  record  and  monitor  the  initiation  and 
development  of  cracks  at  various  points  on  the  aircraft.  The  goal  is  to  be  able  to  detect 
the  degradation  of  the  aircraft  structure  and  to  avoid  critical  failures.  Monitoring 
the  crack  length  (measure  of  the  damage),  the  crack  growth  (which  defines  the  rate 
of  damage  accumulation),  and  the  prediction  of  the  fracture  point  of  a  component 
should  be  made  with  an  accuracy  that  will  allow  the  aircraft  to  be  operated  within 
the  acceptable  risk  levels.  The  basic  idea  behind  damage  monitoring  is  depicted  in 
Figure  2.10. 
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Figure  2.10:  Principle  of  Damage  Monitoring  [13] 


The  corrosion  prevention  plans  are  also  part  of  the  fatigue  management  pro¬ 
grams.  The  prevention  of  corrosion  is  a  major  issue  for  aircraft  manufacturers  and 
operators.  The  reason  is  that  it  is  difficult  to  detect  the  initiation  point  of  corrosion. 
Also,  the  effects  of  corrosion  on  the  system  increase  nonlinearly  as  the  age  increases. 

The  individual  aircraft  tracking  program  (IAT),  used  as  part  of  the  fatigue 
management  program,  allows  the  development  of  a  maintenance  schedule,  including 
inspections,  repairs,  and  modifications  for  each  individual  aircraft.  It  also  allows  the 
maintenance  to  be  scheduled  and  performed  not  based  on  flight  hours  but  on  the  actual 
fatigue  loads  and/or  crack  lengths  of  the  aircraft.  Such  a  program  is  very  beneficial 
especially  when  there  is  great  variability  in  the  operational  use  of  the  aircraft  among 
different  users  (e.g.  different  squadrons).  It  allows  the  identification  of  usage  trends, 
the  controlled  life  consumption  of  the  system,  and  the  modification  of  the  operational 
usage  (if  necessary).  Moreover,  the  operators  do  not  need  to  rely  on  fleet-wide  average 
parameters  since  each  aircraft  is  being  monitored  individually. 

2.4.2  Health  Monitoring  Systems.  The  basic  idea  behind  the  health  moni¬ 
toring  systems  is  a  system  that  is  installed  on  an  aircraft  and  continuously  monitors 
parameters  such  as  strain,  vibrations,  electrical  signals,  acoustic  waves,  temperatures, 
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etc  exercised  on  the  components/systems  during  their  operation.  The  health  mon¬ 
itoring  system  would  allow  the  operators  to  obtain  frequent  views  of  the  systems 
condition  instead  of  getting  snapshots  whenever  an  inspection  is  performed.  These 
frequent  views  of  the  system  would  allow  the  operators  to  diagnose  the  condition  of 
the  aircraft  at  any  moment  during  its  life  and  make  predictions  about  its  future  state. 
A  system  performing  this  monitoring  could  consist  of  a  set  of  sensors  installed  on 
the  components  or  the  aircraft  structure.  Figure  2.11  represents  a  depiction  of  this 
concept. 

A  health  monitoring  system  is  the  most  advanced  NDE  method.  It  allows  non¬ 
destructive  inspections  to  be  performed  continuously  on  numerous  points  of  the  sys¬ 
tem,  even  the  most  inaccessible  areas,  and  (comparing  with  the  conventional  NDI) 
provides  frequent  views  of  the  system’s  condition.  This  way  the  NDE  technology 
becomes  an  integral  part  of  the  aircraft  structure. 


Structure  Wiring  +Sensors  Structure  with  Integrated 

Monitoring  System 

Figure  2.11:  Monitoring  Integration  on  a  Structure  [7] 

The  first  applications  of  monitoring  systems  were  designed  basically  to  moni¬ 
tor  the  operation  of  electronic  components  found  in  avionics  and  flight  control  sys¬ 
tems.  Other  early  monitoring  systems  were  capable  of  performing  loads  monitoring 
of  specific  areas  on  the  aircraft  structure  and  the  engine  components.  These  sys¬ 
tems  collected  loading  and/or  flight  data  from  different  points  via  sensors  or  through 
the  existing  parts  of  the  aircraft.  For  example,  pressure  sensors  that  are  part  of  the 
operation  of  an  engine  subsystem  are  being  used  also  for  collecting  data  for  mon¬ 
itoring  purposes.  These  systems  had  limited  analysis  capabilities.  They  recorded 
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the  collected  data  which  was  later  downloaded  into  a  workstation  for  analysis  and 
evaluation.  The  loads  monitoring  and  flight  data  recordings  were  not  continuous  and 
were  limited  by  the  processing  capabilities  and  storage  capacity  of  the  monitoring 
system’s  electronic  parts.  From  the  characteristics  of  the  monitoring  systems  as  de¬ 
scribed  above,  it  is  apparent  that  these  early  systems  were  not  truly  integrated  with 
the  aircraft. 

In  those  early  monitoring  systems  designs,  the  gauges  had  to  be  very  close  to 
the  monitored  area.  The  efficiency  of  these  systems  was  largely  dependent  on  whether 
an  area  was  monitored  and  the  occurrence  of  the  damaging  event  was  recorded.  This 
means  that,  since  only  specific  points  were  monitored,  if  a  damaging  event  occurred 
at  another  point,  it  might  not  have  been  recorded. 

As  the  sensors  technology  advanced,  new  smaller,  less  expensive,  and  more 
reliable  sensing  devices  were  developed.  With  the  new  technologies,  it  became  feasible 
for  the  sensing  and  actuation  devices  to  be  integrated  with  the  components  and  the 
structure.  The  most  widely  used  types  of  sensing  devices  are  piezoelectric  and  fiber 
optic  sensors. 


Figure  2.12:  Evolution  of  Fatigue  Monitoring  Systems  [7] 


Piezoelectric  sensors  are  mainly  used  to  monitor  accelerations  and  vibrations. 
New  designs  of  ceramic  piezoelectric  sensors  can  be  bonded  on  the  structural  surfaces 
and  can  even  be  integrated  into  composite  materials  (smart  layer  concept).  The  fiber 
optic  sensors  have  the  advantages  of  being  lightweight,  highly  sensitive,  and  only 
require  low-power  consumption.  These  sensors  can  have  a  long  lifetime  and  low  costs 
but,  on  the  other  hand  they  are  difficult  to  repair  [13]. 
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Together  with  the  progress  in  the  sensors  design  came  a  shift  towards  the  concept 
of  an  ISHMS.  The  purpose  of  such  a  system  is  to  continuously  monitor  the  aircraft’s 
hot  spots  and  to  be  able  to  perform  an  analysis  of  the  recorded  data  and  generate 
maintenance  recommendations.  With  an  ISHMS,  it  is  not  necessary  to  monitor  the 
entire  aircraft;  only  the  most  critical  locations  need  to  be  monitored.  Networks  of 
sensors  monitoring  these  critical  locations  are  designed  and  improved  diagnostics  al¬ 
gorithms  are  developed.  The  ultimate  goal  of  these  sophisticated  ISHM  systems  is  to 
function  as  the  nervous  system  of  the  aircraft. 

The  use  of  the  existing  health  monitoring  systems  has  shown  that  these  systems 
can  help  reduce  the  maintenance  related  costs  during  the  life  cycle  of  an  aircraft  and 
can  improve  the  systems  reliability.  They  can  also  help  to  migrate  from  the  schedule 
based  maintenance  (the  traditional  approach)  to  conditional  based  maintenance  on 
the  aircraft. 

Currently,  the  community  is  at  a  turn  in  the  evolution  of  SHMS.  Manufacturers 
and  researchers  from  all  over  the  world  are  working  on  the  development  of  new  types 
of  sensors,  such  as  thermal,  or  sensors  that  are  using  acoustic  or  electromagnetic 
waves,  in  order  to  improve  the  direct  damage  monitoring.  They  are,  also  trying  to 
combine  the  sensors  into  networks  and  to  integrate  the  monitoring  systems  into  the 
new  aircraft  systems  during  the  design  phase.  A  higher  degree  of  customization  in 
the  maintenance  of  each  aircraft  and  fleets  being  used  for  longer  time  (service  lives 
of  40-50  years  will  be  more  common)  are  expected  as  a  result  of  the  use  of  advanced 
ISHMS. 

In  general,  one  can  discern  a  trend  towards  the  automation  of  the  inspection 
process  and  other  maintenance  actions.  Besides  NDI  methods  and  the  design  of  ad¬ 
vanced  monitoring  systems,  other  efforts  include  the  robot  assisted  inspections,  where 
specially  designed  and  equipped  robots  are  used  instead  of  technicians  to  perform  the 
visual  and  NDI/NDE.  The  advantage  of  this  concept  is  the  use  of  these  robots  allows 
the  performance  of  inspections  in  areas  hard  to  reach  with  small  effort  and  minimum 


teardown.  The  data  collected  from  the  robots  is  transferred  to  a  workstation  where 
the  data  is  further  analyzed. 

2.5  Aging  Aircraft  Problem 

In  the  recent  years,  an  increase  in  the  number  of  aircraft  flying  throughout 
the  world  has  been  observed.  A  large  number  of  these  aircraft  have  become  aging 
(e.g.  aircraft  that  have  been  flying  for  more  than  15  years)  [13].  This  percentage  is 
continually  increasing.  There  is  also  an  increasing  number  of  military  aircraft  that 
have  been  flown  for  more  than  40  years  (e.g.  F-4,  C-135,  B-52).  Additionally,  many 
mature  aircraft  are  reaching  the  end  of  their  design  life. 

At  the  same  time,  many  aircraft  operators,  both  commercial  airlines  and  gov¬ 
ernments  operating  military  aircraft,  have  to  deal  with  financial  hardships  as  a  result 
of  budgetary  restrictions.  Since  they  have  aging  aircraft  in  their  inventory,  these 
operators  have  to  decide  whether  to  choose  the  (usually)  more  expensive  alternative 
of  purchasing  new  systems  or  continue  using  their  existing  aircraft.  Very  often,  the 
operators’  decision  is  to  try  to  get  as  much  benefit  as  possible  out  of  their  investment 
before  they  retire  their  aircraft.  Operators  are  also  seeking  a  more  efficient  use  of 
their  systems.  This  creates  a  worldwide  demand  for  continued  use  of  aging  aircraft 
fleets. 

This  demand,  though,  is  not  easy  to  satisfy.  As  the  aircraft  age  increases, 
the  problems  generated  by  fatigue  and  corrosion  increase.  Increased  numbers  of  in¬ 
spections  and  other  maintenance  actions  (repairs,  modifications)  are  required,  which 
usually  leads  to  decreased  system  availability.  The  maintenance  related  costs  (which 
is  the  biggest  cost  driver)  and  the  safety  risks  (mainly  due  to  fatigue  problems)  are 
also  increasing  while  the  increased  age  creates  restrictions  in  the  operational  use  of 
the  aircraft  (e.g.  configuration  limitations,  flight  envelope  restrictions).  Therefore, 
for  aircraft  that  are  reaching  their  design  life,  a  life  extension  is  needed. 
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The  aging  problem  became  even  more  important  after  the  Aloha  airlines  ac¬ 
cident  in  the  1980’s.  That  accident  resulted  in  stricter  airworthiness  requirements 
and  created  pressure  from  the  FAA  towards  the  aircraft  systems  industry  to  deal 
with  the  aging  aircraft  problem.  The  stricter  requirements  translated  into  increased 
maintenance  actions  and  costs. 

This  thesis  mentioned  that  the  problems  generated  by  fatigue  and  corrosion  are 
increasing  with  the  system’s  age.  Cyclic  fatigue  degrades  the  structural  life  capability, 
and  its  effects  are  even  more  substantial  when  combined  with  corrosion.  This  is  not 
a  big  problem  for  the  mechanical,  or  the  high-cost  electronic  components,  or  even 
the  engines,  since  these  parts  can  be  easily  replaced.  However,  when  it  comes  to  the 
aircraft  structure  (which  has  a  relatively  low-cost),  the  effects  of  fatigue  and  corrosion 
combined  with  the  age,  becomes  a  very  serious  problem.  The  reason  is  because  the 
structure  cannot  be  easily  modified,  let  alone  replaced,  after  it  has  been  designed  and 
manufactured. 

There  have  been  many  different  approaches,  or  design  philosophies,  that  tried 
to  deal  with  the  age  generated  fatigue  and  the  life  extension  problems.  Examples  of 
such  design  philosophies  are  the  safe-life  design ,  fail-safe  design  and  damage  tolerant 
design.  Several  life  extension  concepts  such  as  the  SLEP  and  the  ASIP  have  been 
implemented.  Each  of  these  approaches  has  been  used  in  different  aircraft  types. 
Sometimes  different  approaches  or  combinations  of  approaches  have  been  used  for  the 
same  aircraft  type.  Historically,  one  could  say  that  both  approaches  have  been  used 
equally  on  all  the  aircraft  types  that  required  a  life  extension. 

2.5.1  Safe-Life  Design.  The  main  idea  of  the  Safe-Life  design  concept  is 
that  the  components  and  the  structures  are  designed  in  such  a  way  so  that  they 
can  survive  throughout  their  specified  design  life.  This  means  that  the  components 
are  expected  to  function  without  any  maintenance  requirements  (fatigue  inspections, 
repairs,  modifications,  etc),  and  are  being  replaced  as  soon  as  they  reach  a  specified 
time.  The  replacement  at  the  specified  time  is  being  done  in  order  to  maintain  the 
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desired  safety  level.  In  order  to  determine  the  inspection  intervals  and  the  replacement 
time  in  the  safe  life  approach,  the  designers  are  trying  to  forecast  the  crack  initiation 
and  growth. 

The  replacement  of  the  components  at  a  predetermined  time,  though,  is  a  rather 
conservative  approach.  At  the  time  of  replacement,  the  components  may  not  have 
fatigue  cracks  long  enough  to  justify  their  condemnation.  As  a  result,  the  condemned 
parts  may  still  have  some  useful  life  remaining,  which  is  wasted.  If  a  crack  has 
initiated  and  has  grown  on  a  component  before  it  reaches  its  design  life,  then,  as  soon 
as  the  crack  is  discovered  (during  inspection),  it  has  to  be  repaired  resulting  in  aircraft 
downtime  and  maintenance  costs.  The  safe-life  design  approach,  also,  does  not  take 
into  consideration  the  corrosion,  which,  as  it  was  mentioned  earlier,  combined  with 
the  fatigue  can  have  serious  impact  on  the  component. 

According  to  the  fail-safe  design  philosophy,  the  components  or  structures  are 
designed  so  that,  if  they  ever  fail,  their  failure  will  occur  in  such  a  way  that  it  will 
cause  the  minimum  damage  to  the  system.  This  philosophy  is  trying  to  overcome  the 
disadvantage  of  wasting  useful  life  as  experienced  in  the  safe-life  design. 

2.5.2  Damage  Tolerance  Design.  Another  philosophy  is  the  Damage  toler¬ 
ance  design.  This  term  is  used  to  describe  the  design  of  a  system  that  has  the  ability 
to  withstand  damage.  Safety-by-inspection  is  the  main  idea  behind  this  design.  The 
objective  of  such  a  design  is  to  ensure  that  cracks  do  not  grow  beyond  a  critical  size 
(i.e.  a  size  that  could  affect  the  system’s  safety  level)  during  the  component’s  design 
life.  In  order  to  design  a  component  and  a  system  using  this  philosophy,  there  are 
some  issues  that  need  to  be  answered: 

•  What  types  of  loads  will  be  exercised  on  the  component  during  its  operational 

life? 

•  What  are  the  sizes  of  these  loads? 
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•  How  long  can  the  component  endure  operating  under  this  loading  before  a  failure 
occurs? 

•  Once  a  crack  has  initiated  on  the  component,  how  long  will  it  take  until  it 
reaches  a  critical  size? 

The  other  part  of  the  aging  aircraft  problem,  besides  dealing  with  the  age  gen¬ 
erated  fatigue,  is  how  to  extend  the  aging  aircraft’s  service  life.  Using  the  results  of 
aircraft  loading  analysis,  corrosion  and  fatigue  testing,  and  damage  tolerance  analy¬ 
sis,  the  engineers  can  extend  the  aircraft’s  service  life  for  a  number  of  flight  hours. 
The  goal  is  to  determine  inspection  intervals  that  will  guarantee  the  required  safety 
level.  This  extension  is  usually  accompanied  by  some  restrictions  on  the  operational 
use  (e.g.,  limitations  in  the  flight  envelope)  and  by  more  detailed  and  more  extensive 
inspections. 

2.5.3  SLEP.  One  solution  that  has  been  developed  to  achieve  this  service- 
life  extension  for  various  aircraft  types  is  the  SLEP.  This  solution  involves  the  iden¬ 
tification  of  the  fatigue  critical  structural  components  on  an  aging  aircraft  and  their 
subsequent  replacement  or  modification  before  the  service  life  can  be  extended.  The 
purpose  of  these  replacements  and  modifications  is  to  ensure  that  the  affected  com¬ 
ponents  will  be  able  to  operate  throughout  the  extension  period  without  the  require¬ 
ment  for  any  additional  maintenance  (inspections,  repairs,  modifications,  etc),  an  idea 
which  is  encountered  in  the  safe- life  design  concept.  The  identification  of  those  fatigue 
critical  areas  and  the  replacement  or  modification  of  the  components  is  usually  a  time 
consuming  process  and  requires  a  lot  of  effort  to  assess  the  effects  of  these  mainte¬ 
nance  actions  to  the  safety  level.  The  mid-life  upgrade  programs  that  are  developed 
for  the  various  aircraft  types  are  also  in  the  same  direction  as  the  SLEP. 
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2.5.4  ASIP.  The  other  major  concept  that  has  been  implemented  in  order 
to  extend  the  service  life  of  various  aging  aircraft  is  the  ASIP.  The  basic  idea  of  ASIP 
is  to  perform  a  major  structural  inspection  after  a  number  of  flight  hours  or,  even 
better,  a  number  of  fatigue  cycles  have  accumulated,  instead  of  replacing  the  critical 
components  based  on  their  accumulated  operation  time  as  in  SLEP.  The  time  this 
inspection  will  be  performed  differs  for  each  individual  aircraft.  The  areas  where 
problems  (fatigue  cracks,  corrosion)  are  identified  can  be  either  repaired  or  replaced. 
ASIP  is  more  related  to  the  damage  tolerance  design  philosophy. 

In  order  to  develop  and  apply  an  ASIP,  the  identification  of  the  structural  critical 
locations  is  required.  This  is  being  done  by  using  the  results  of  the  Major  Airframe 
Fatigue  Test  (MAFT)  conducted  during  design.  Information  obtained  from  periodic 
scheduled  maintenance  performed,  after  the  aircraft  goes  into  service,  is  being  used 
to  update  the  MAFT  results.  Based  on  this  information,  the  areas  where  WFD  in 
aging  aircraft  occurs,  are  identified.  These  areas  require  special  attention  during  the 
structural  inspection  to  ensure  timely  detection  of  fatigue  damage. 

Subsequently,  a  structural  inspection  program  is  developed  with  the  purpose  to 
inspect  and,  if  necessary,  repair  the  critical  areas.  Extensive  teardown  inspections  are 
included  in  the  structural  inspection  program  as  well  as  NDI  (ultrasound  and  eddy- 
current  inspections  are  essential  actions  in  ASIP),  component  testing,  and  full-scale 
fatigue  tests.  Theoretical  models  are  also  being  used  to  estimate  and  forecast  the 
fatigue  effects. 

A  result  of  the  above  analysis  is  a  customized  inspection  schedule  for  each 
individual  aircraft.  Other  results  are  major  modifications  and/or  repairs  aiming  to 
improve  the  structural  integrity  of  the  aircraft.  These  modifications/repairs  are  also 
customized  for  each  individual  aircraft.  This  customization  refers  to  both  the  extent 
of  the  inspections/repairs/modifications  and  the  timeframe  these  maintenance  actions 
are  going  to  be  performed. 
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In  the  early  ASIP  plans,  that  were  developed  for  various  aircraft,  only  the  effects 
of  fatigue  were  taken  into  consideration.  The  effects  of  corrosion  on  aging  aircraft  and 
actions  to  deal  with  those  were  not  included.  This  approach  has  changed  in  the  recent 
years  and  corrosion  prevention  and  repair  is  now  part  of  an  ASIP  plan. 

After  the  installation  of  early  SHMS  on  some  aircraft  types,  obtaining  and  an¬ 
alyzing  loading  data  for  each  aircraft  became  possible.  This  data  was  also  used  to 
assess  the  structural  integrity  of  the  aircraft  and  to  develop  the  ASIP  plan,  simulta¬ 
neously  increasing  the  degree  of  customization  in  the  maintenance  of  each  individual 
aircraft. 

The  application  of  the  concepts  discussed  above  by  many  manufacturers  and 
operators  around  the  world  allowed  the  safe  service-life  extension  on  many  aircraft 
types  and  provided  some  solutions  for  the  aging  aircraft  problem. 

2.6  T-37  and  A-37  Historical  Background 

The  A-37  aircraft  is  part  of  a  long  evolution  of  the  T-37  trainer  aircraft,  which 
was  modified  extensively  to  satisfy  varying  mission  needs  and  engineering  designs. 
In  order  to  fully  understand  the  history  of  the  A-37  aircraft,  it  is  necessary  to  start 
by  explaining  the  development  of  its  predecessor,  the  T-37  aircraft.  During  the  early 
1950’s  the  USAF  decided  that  a  lower  performance  jet  trainer  was  needed  to  bridge  the 
gap  between  the  propeller-driven  trainers  and  Lockheed’s  advanced  jet  T-33  Shoot¬ 
ing  Star  being  used  in  the  pilot  training  curriculum  [62].  In  the  fall  of  1952,  eight 
manufacturers  submitted  a  total  of  fifteen  designs  during  the  Request  for  Proposals 
phase.  The  Cessna  Aircraft  Company  won  the  contract  with  their  Model  318  pro¬ 
posal,  designated  the  T-37  (nicknamed  Tweet)  by  the  USAF.  The  contract  required  a 
total  of  three  prototype  aircraft  and  the  first  XT-37  prototype  made  its  initial  flight 
on  12  October  1954.  After  extensive  flight  tests  and  several  modifications,  the  USAF 
ordered  11  pre-production  T-37A  aircraft.  The  first  was  delivered  and  accepted  in 
September,  1955.  However,  the  T-37A  did  not  enter  USAF  operational  service  until 
the  summer  of  1957,  when  it  was  used  by  Air  Education  and  Training  Command 
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to  teach  student  pilots  basic  military  maneuvers  and  techniques,  excluding  ordnance 
delivery  and  in-flight  refuelling  [62], 

2.6.1  T-37  (Tweet)  Development.  The  original  T-37A  aircraft  had  an  empty 

weight  of  3,870  pounds  and  a  maximum  gross  weight  of  6,400  pounds  [62],  Each  of 
the  twin-engines  generated  only  920  pounds  of  thrust.  The  T-37A  aircraft  impressed 
USAF  maintenance  personnel  for  its  ease  of  maintenance,  easy  access  to  all  com¬ 
ponents,  and  low  overall  maintenance  requirements  [62],  A  total  of  534  A- models, 
including  the  11  preproduction  units,  were  manufactured  by  October,  1959.  In  early 
1959,  Cessna  and  the  USAF  agreed  on  a  configuration  update  for  the  T-37  and  on  6 
November  1959,  the  first  T-37B  was  introduced  into  the  USAF  fleet  [62],  Among  the 
most  significant  modifications  were: 

1.  New  1,025  pound  thrust  Continental/Teledyne  J69-T-25  engines. 

2.  A  very  high  frequency  omni-directional  navigation  receiver. 

3.  Military-standard  Ultrahigh  Frequency  (UHF)  radio  transceiver. 

4.  A  redesigned  instrument  panel  layout. 

In  total,  552  T-37B  aircraft  were  produced  between  1959  and  1968,  many  of 
which  were  A-models  retrofitted  to  the  improved  B-model  standards.  At  the  same 
time,  Cessna  and  the  USAF  engaged  in  a  military  sales  campaign  to  deliver  T-37 
aircraft  to  several  countries  under  the  Military  Assistance  Program  (MAP)  [62], 

The  T-37’s  flight  control  system  is  basic  and  conventional:  all  primary 
flight  controls  (ailerons,  elevators,  and  rudder)  are  operated  via  cables, 
pulleys,  cranks,  and  push-pull  rods  while  secondary  flight  controls  (aileron 
trim  tab,  elevator  trim  tab,  and  rudder  trim  tab)  are  electrically  operated 
from  the  cockpit.  The  fuel  system  consists  of  three  fuel  tanks;  one  on  each 
wing  and  one  in  the  fuselage.  The  aircraft’s  onboard  fuel  capacity  was 
2,000  pounds  (309  gallons)  of  fuel  with  a  maximum  range  of  470  nautical 
miles  without  external  fuel  tanks.  [62] 

As  a  trainer  aircraft,  the  T-37  was  considered  a  perfect  introduction  to  military 
jet  aviation  because  of  its  outstanding  safety  record,  its  side-by-side  seat  arrangement, 
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as  well  as  for  its  maneuverability  and  stability  throughout  its  flight  envelope  [62],  In 
addition,  the  T-37’s  acquisition  and  operating  costs  were  the  lowest  on  record. 

2.6.2  A-37  ( Dragonfly )  Development.  In  1961,  Cessna  used  a  T-37B  as  the 
prototype  for  a  new  fighter  aircraft  model  designated  T-37C  [62].  The  concept  resulted 
from  USAF  interest  in  a  small,  cheap  combat  aircraft  for  counterinsurgency  operations 
against  fast,  well-armed  guerrilla  forces.  The  aircraft  was  intended  primarily  for 
export  to  foreign  air  forces  that  could  not  afford  the  current  front-line  jet  fighters.  In 
order  to  allow  carriage  of  the  external  stores,  Cessna  had  to  increase  the  structural 
strength  of  the  wing  spars.  The  new  design  included  jettisonable  65-gallon  wingtip 
fuel  tanks  and  a  single  weapons  station  under  each  wing.  For  weapons  delivery,  the 
T-37C  incorporated  a  K-14C  computing  gunsight  and  an  AN-N-6  16mm  gun  camera. 
Each  pylon  could  carry  a  rocket  pod,  a  gun  pod,  a  bomb  of  up  to  250  pounds,  or  an 
AIM-9  Sidewinder  air-to-air  missile.  However,  the  modified  aircraft  was  10%  slower 
because  it  used  the  same  engines  even  though  its  gross  weight  was  increased  by  2,000 
pounds.  The  T-37  fighter  concept  provided  limited  ground  attack  capability,  but 
according  to  Shiel,  the  aircraft  was  really  suitable  only  as  a  ground  attack  training 
aircraft  [62],  A  total  of  273  T-37C  aircraft  were  built  and  all  were  sold  to  foreign 
countries  under  the  MAP. 

In  1963,  the  USAF  Aeronautical  Systems  Division  at  Wright-Patterson  Air  Force 
Base  (AFB)  issued  a  contract  to  Cessna  for  the  development  and  evaluation  of  two 
YAT-37D  prototypes  [62],  The  most  significant  changes  were: 

1.  Two  General  Electric  J85-J-2/5  engines  each  generating  2,400  pound  thrust. 

2.  A  total  of  three  weapon  stations  under  each  wing. 

3.  Armor  plating  (7/32- inch  steel)  on  the  cockpit  floor  and  behind  the  seats  for 
protection  against  ground  fire  from  up  to  30  caliber  weapons. 

4.  Self-sealing  fuel  tanks  able  to  sustain  penetration  by  up  to  30  caliber  weapons. 

5.  Vortex  generators  located  on  top  of  the  wings 
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6.  GE  GAU-2B/A  7.62mm  Minigun  mounted  in  the  nose  compartment  with  1,500 

rounds  of  ammunition. 

7.  Mk  Mod  4  gun  sight  mounted  in  front  of  the  pilot. 

8.  Wingtip  mounted  95-gallon  external  fuel  tanks. 

9.  Larger  wheels  and  tires  for  use  on  unimproved  runways. 

10.  Special  avionics  package  for  communication,  navigation,  and  target  acquisition. 

After  all  flight  tests  and  evaluations  were  performed,  the  prototypes  did  not 
lead  to  a  production  contract  and  on  December,  1964  the  prototypes  were  retired  [62], 
Nevertheless,  the  USAF  again  became  interested  in  the  YAT-37  as  a  replacement  for 
the  aging  Douglas  A-1E  Skyraiders,  which  were  performing  well  in  the  Vietnam  War, 
but  were  sustaining  heavy  combat  losses  [32], 

In  August  1966,  the  two  retired  YAT-37  were  refurbished  and  a  fourth  external 
weapons  pylon  was  added  under  each  wing  [62],  The  USAF  issued  a  contract  for 
the  delivery  of  39  AT-37D  aircraft,  which  were  redesignated  A-37A,  to  be  tested  in 
combat  in  South  Vietnam  under  Operation  Combat  Dragon.  In  the  aircraft’s  first 
3,000  combat  sorties,  no  A-37A  aircraft  were  lost  to  hostile  fire  [32],  The  Combat 
Dragon  Operation  evaluated  the  aircraft  on  its  performance  on  close  air  support, 
escort,  and  armed  reconnaissance  missions.  The  evaluation  identified  several  areas  for 
improvement,  which  led  to  the  development  of  the  A-37B  Dragonfly  (Cessna  Model 
318E)  and  a  $3.6  million  USAF  contract  for  the  delivery  of  197  new  A-37B  aircraft. 
In  addition,  the  contract  required  the  airframe  to  be  strengthened  to  a  maximum 
gross  weight  of  14,000  pounds  and  to  include  in-flight  refueling  capabilities.  However, 
many  of  the  basic  systems  on  the  A-37  aircraft,  such  as  hydraulics  and  electrical 
components,  were  the  same  as  those  found  on  the  original  T-37  aircraft  [62], 

Most  A-37B  aircraft  Cessna  produced  were  exported  under  the  MAP,  many  of 
those  going  to  South  and  Central  American  countries  (Table  2.1)  [62].  Additional 
A-37  aircraft  were  later  provided  to  MAP  countries  as  the  aircraft  were  removed 
from  active  USAF  service.  Some  of  the  exported  aircraft  had  the  refueling  probe 
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Table  2.1:  A-37  deliveries  to  the  MAPA  countries  [62] 

A-37  Deliveries  to  South  and  Central  America 


Country 

Quantity 

Year 

Notes 

Chile 

34 

1974-75 

Colombia 

26 

1980 

including  12  for  anti-drug  efforts 

Ecuador 

12 

1975 

El  Salvador 

21 

1983-84 

including  3  replacements  in  1991 

Guatemala 

13 

1969,  1973 

Honduras 

15 

1974-75 

Peru 

36 

1974-75 

including  last  production  A-37B 

Uruguay 

12 

1975 

removed  or  replaced  with  a  shorter  probe  for  use  as  a  single-point  ground  refueling 
system.  Since  then,  the  A-37  aircraft  has  proved  to  be  an  ideal  aircraft  for  operation 
by  countries  with  limited  defense  budgets  and  smaller,  less  technologically  advanced 
air  forces  [62], 

Despite  their  success,  many  of  the  existing  T-37  and  A-37  aircraft  are  approach¬ 
ing  or  have  exceeded  the  end  of  their  design  life.  During  the  last  two  decades,  the 
USAF  has  developed  and  implemented  several  programs  designed  to  extend  the  life 
of  these  aircraft  without  jeopardizing  the  safety  of  flight.  Two  of  these  programs  are 
the  A-37  SLEP  and  the  A-37  ASIP,  both  of  which  will  be  briefly  discussed  in  the 
following  sections. 

According  to  the  2005  Air  Force  Almanac,  there  are  still  283  T-37  aircraft  in 
USAF  inventory  with  an  average  age  of  40.8  years  [6].  There  are  only  two  older  air¬ 
frames  in  the  USAF  inventory,  namely  the  B-52  with  42.8  and  the  C-135  with  42.6 
years  respectively.  Even  though  these  life  extension  programs  have  been  quite  success¬ 
ful  in  accomplishing  their  goals,  the  reality  is  that  the  T-37  and  A-37  airframes  are 
requiring  an  increasing  amount  of  preventive  maintenance  and  inspections.  In  most 
instances,  this  means  extensive  grounding  time  and  escalating  maintenance  costs, 
which  ultimately  affects  mission  accomplishment.  The  USAF  has  decided  to  replace 
their  aging  T-37  fleet  with  Raytheon’s  T-6  Texan  II  aircraft.  However,  some  MAP 
countries  have  limited  budgets  and  can  not  afford  the  replacement  of  their  aging  A- 
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37  or  T-37  fleet.  These  countries  would  prefer  to  see  the  development  of  an  aircraft 
structural  health  monitoring  system  that  would  allow  the  continued  operation  of  their 
aircraft  without  the  increased  maintenance  burden. 

2.6.3  Life  Extension.  Documentation  on  the  service  life  of  both  the  T-37 
and  the  A-37  aircraft  is  quite  limited  mainly  because  these  are  outdated  airframes. 
In  addition,  information  on  the  A-37  aircraft  is  usually  harder  to  find  because  it 
is  no  longer  in  the  USAF’s  inventory,  nor  is  it  easily  accessible  because  of  foreign 
policies  and  clauses.  Furthermore,  there  are  many  factors  that  can  affect  an  aircraft’s 
service  life  and  those  factors  can  vary  drastically  between  countries,  which  further 
complicates  the  task  of  accurately  and  precisely  estimating  the  additional  service  life 
of  a  fleet  of  aircraft.  For  example,  environmental  factors,  aircraft  loading  factors,  the 
aggressiveness  of  the  flying  profiles,  operational  usage  tempo,  maintenance  schedules 
and  procedures  are  only  some  factors  that  can  have  a  tremendous  impact  on  the  service 
life  of  each  individual  aircraft.  Nevertheless,  the  thesis  group  was  able  to  contact  the 
Ogden  Air  Logistics  Center,  Mature  &  Proven  Aircraft  Directorate  (MAPA),  Integrity 
and  Analysis  Engineering  Branch  (OO-ALC/LCEI)  at  Hill  AFB  who  provided  some 
information  on  the  T-37  SLEP,  the  T-37  ASIP  and  the  A-37  safe-life  programs.  The 
following  is  a  compilation  of  the  procedures  and  findings. 

2.6.4  T-37  SLEP.  Cessna  Aircraft  Company  initially  estimated  the  T-37’s 
original  design  life  to  be  8,000  flight-hours  and  20,000  landings  [60].  According  to 
the  publication  Cessna  Warbirds,  between  June  1969  and  December  1970,  Cessna’s 
Military  Twin  Division  conducted  an  exhaustive  fatigue  life  testing  program  on  the  T- 
37B  with  the  goal  of  extending  the  Tweet’s  life  to  15,000  flying  hours.  After  extensive 
testing,  Cessna  engineers  identified  several  critical  fatigue  areas  that  were  not  being 
monitored  at  that  time.  In  addition,  Cessna  recommended  three  specific  structural 
modifications,  all  of  which  were  approved  by  the  USAF  and  allowed  the  T-37B  fleet 
to  achieve  the  target  15,000-hour  service  life.  I11  1988,  almost  20  years  later,  the 
USAF  completed  a  durability  and  damage  tolerance  analysis  and  determined  that 
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the  T-37  fleet  was  flying  at  risk  [18].  Later  in  August  of  1989,  with  many  T-37 
aircraft  approaching  the  15,000-hour  limit,  Sabreliner  Corporation  was  awarded  a 
contract  to  design  and  implement  a  SLEP  that  involved  the  modification  of  four 
major  structural  components  that  included:  (1)  the  forward  lower  wing  spar,  (2)  the 
fuselage  forward  carry-through  structure,  (3)  the  horizontal  stabilizer  and  (4)  the 
horizontal  stabilizer  support  structure  called  the  banjo  fittings.  The  objective  of  the 
T-37  SLEP  was  to  extend  the  life  of  the  T-37  fleet  such  that  it  would  be  inspection-free 
in  the  SLEP-modified  areas  for  at  least  an  additional  8,000  flight  hours.  Southwest 
Research  Institute  (SwRI)  served  as  principal  subcontractor  responsible  for  most  of 
the  engineering  work  performed  during  the  T-37  SLEP.  SwRI  identified  and  ranked 
the  T-37  FCLs  in  the  SLEP-modified  areas  of  the  aircraft.  As  a  result,  the  majority 
of  the  FCLs  originally  documented  by  Cessna  Corporation  were  eliminated.  The 
concluding  remarks  of  the  report  indicate  that: 

The  SLEP  full-scale  aircraft  durability  and  tolerance  testing,  together  with 
the  SLEP  damage  tolerance  analysis,  demonstrated  that  all  modified  areas 
would  be  inspection-free  for  at  least  8,000  flight  hours.  [18] 

During  the  1990s,  six  T-37  aircraft  were  instrumented  with  flight  load  data 
recorders  (FLDR)  in  an  effort  to  characterize  the  way  these  aircraft  were  being  flown 
in  the  Undergraduate  Pilot  Training,  Instructor  Pilot  Training,  and  Euro-NATO  Joint 
Jet  Pilot  Training  programs.  The  data  from  the  FLDRs  was  used  to  update  the  SLEP 
damage  tolerance  analysis  performed  in  October  1998  and  indicated  that  the  8,000 
flight  hour  inspection-free  goal  was  still  being  met  in  most  SLEP  FCLs.  The  following 
table  shows  a  compilation  of  the  FCLs  identified  in  the  1998  SLEP  study  (Figure  2.13). 

2. 6. 5  T-37  ASIP.  The  ASIP  master  plan  was  developed  for  the  T-37  aircraft 

and  is  revised  annually  by  Ogden  Air  Logistics  Center  [60] .  The  purpose  of  the  ASIP 
master  plan  is  to  define  and  document  the  specific  approach  to  accomplish  the  various 
ASIP  tasks  throughout  the  life-cycle  of  each  individual  flight  vehicle  [60].  The  plan 
depicts  the  time-phased  scheduling  and  integration  of  all  required  ASIP  tasks  for 
design,  development,  qualification,  and  tracking  of  the  airframe.  The  plan  includes 
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FCL 

FC  L  Description 

Material 

Appendix  A 
Figure  Number 

CT11 

Wing  Fitting  Center  Lug  Edge 

7050-T74  die  forging 

A-3,  A-4 

W6 

Strap  Lug  Radius 

4340  Steel 

A-2 

W1 

Spar  Cap  Edge  @  WS  55.76 

7075-T73511  extnision 

A-l 

W4 

Strap  Lug  Hole 

4340  Steel 

A-2 

E2 

Edge  at  Top  Stabilizer  Attach 
Holes  in  Forward  Banjo  Fitting 

7175-T74  die  forging 

A-6 

W3 

Spar  Leading  Edge  Attach 
Hole  @  WS  57 

7075-T73511  extrusion 

A-l 

CT1 

Wing  Fitting  Center  Lug  Holes 

7050-T74  die  forging 

A-3,  A-4 

W2 

Spar  Cap  Hole  @WS  55.76 

7075-T73511  extnision 

A-l 

W5 

First  Strap  Hole 

4340  Steel 

A-2 

W7 

Edge  of  Strap  Below  First 
Attach  Hole 

4340  Steel 

A-2 

CT2 

Hole  at  Lower  Inboard  Wing 
Fittmg  Radius 

7050-T74  die  forgmg 

A-3 

CT5 

Hole  in  Center  Carry-Through 
Caps  @  BL  0.0 

2024-T3511  extnision 

A-5 

6B 

Wing  Rear  Spar  Lower  Cap 
Fitting 

7075-T6  extrusion 

A-7 

6D 

Wing  Rear  Spar  Lower  Cap  @ 
Strap  End 

7075-T6  extnision 

A-S 

Figure  2.13:  T-37  SLEP  FCL  List  [18] 
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discussion  of  unique  features,  exceptions  to  the  guidance  of  military  handbooks  and 
the  associated  rationale,  and  any  problems  anticipated  in  the  execution  of  the  plan. 
The  development  of  the  schedule  considers  all  interfaces,  the  impact  of  schedule  delays 
(e.g.,  delays  due  to  test  failure),  mechanisms  for  recovery  programming,  and  other 
problem  areas  [60]. 

The  success  of  ASIP  was  demonstrated  when  the  initial  8,000  hours  service  life 
of  the  T-37B  aircraft  was  consecutively  increased  to  15,000  hours  and  ultimately  to 
18,000  hours;  more  than  twice  the  original  service  life  [60].  As  previously  mentioned, 
the  first  fatigue  tests  and  analysis  on  the  T-37  A/B  aircraft  were  conducted  in  the 
1960s.  The  study  focused  on  fatigue  analysis  of  the  wing,  main  landing  gear,  and 
support  structure.  The  early  goal  was  to  establish  an  8,000  hour  safe-life  with  a 
scatter  factor  of  two.  However,  early  in  the  ASIP  program  the  goal  was  increased  to 
15,000  safe-life  hours  using  a  scatter  factor  of  two.  This  was  further  revised  to  15,000 
safe-life  hours  using  a  scatter  factor  of  four.  With  the  current  program  of  inspections 
and  modifications,  the  T-37  aircraft  can  safely  reach  a  service  life  of  18,000  flying 
hours  [60]. 

Recently,  the  ASIP  recommended  a  sonic  load  analysis  be  performed  on  the  T- 
37  aircraft  to  identify  any  potential  problem  areas  [60] .  A  sonic  load  analysis  is  a  test 
procedure  to  determine  the  effects  of  sonic  fatigue  reaction  on  the  aircraft  structure. 
Such  fatigue  is  caused  by  a  magnification  of  the  stresses  due  to  noise  operating  at 
or  near  the  frequency  of  the  structure.  A  sonic  investigation  of  the  T-37B  was  made 
and  compared  to  the  YAT-37D.  A  problem,  consisting  of  cracking  rib  flanges  in  the 
horizontal  stabilizer,  was  attributed  to  sonic  fatigue.  The  proposed  ASIP  modification 
resulted  in  retrofitting  the  aircraft  with  horseshoe  clips.  X-ray  inspections  validated 
the  effectiveness  of  this  modification,  which  was  then  incorporated  to  the  entire  T-37 
fleet.  Put  in  other  words,  aircraft  monitoring  programs  such  as  the  SLEP  and  ASIP 
have  proven  to  be  successful  in  elongating  the  life  of  aging  aircraft.  The  goal  of  the 
ISHMS  is  to  provide  a  similar  outcome  while  minimizing  costs  and  maximizing  safety 
of  flight. 
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2.6.6  A-37  SAFE-LIFE.  Most  of  the  information  presented  on  the  previous 
SLEP  and  ASIP  sections  were  based  on  documentation  that  the  thesis  team  found 
on  the  T-37  aircraft.  As  previously  stated,  even  though  the  initial  thesis  target 
was  the  aging  A-37  fleet  of  the  CAF,  the  thesis  team  had  to  re-direct  the  efforts  and 
broaden  the  scope  of  the  thesis  due  to  limited  information  availability  and  accessibility. 
However,  the  thesis  team  did  find  one  document  that  was  relevant  to  the  initial  target 
and  is  briefly  summarized  in  the  following  paragraphs.  Safe-life  is  a  concept  that 
incorporates  margins  of  safety  based  on  probabilistic  data  to  allow  an  aircraft  be 
operated  to  the  design  life  limits  without  having  to  conduct  fatigue  crack  inspections 
[54],  In  December  2002,  representatives  from  12th  Air  Force  asked  MAPA  to  organize 
an  effort  to  determine  the  flying  hours  remaining  on  a  number  of  A-37  aircraft  owned 
by  the  CAF.  The  primary  focus  of  the  NDIs  was  to  determine  the  structural  condition 
of  the  CAF  A-37  aircraft.  However,  according  to  the  report,  the  lack  of  data  from  CAF 
flight  spectrum  prevented  a  safe-life  or  damage  tolerance  assessment  [54],  Basically, 
the  engineering  team  could  not  collect  enough  statistical  data  to  accurately  quantify 
initial  or  recurring  inspection  intervals.  The  conclusion  of  this  inspection  stated  that 
validation  of  the  flying  hours  left  on  the  CAF  A-37  fleet  was  dependent  upon: 

1.  Quantifying  actual  operational  usage. 

2.  Establishing  external  loads  and  a  usage  spectrum. 

3.  Identifying  FCLs  and  stress  spectra  through  finite  element  modeling  (FEM) 
analysis. 

4.  Determining  crack  growth  rates  and  critical  crack  sizes. 

5.  Determining  initial  and  recurring  maintenance  inspection  intervals. 

Once  the  operational  usage  is  known,  external  loads  and  a  usage  spectrum 
can  be  developed,  identifying  FCLs  and  stress  spectra  through  FEM  analysis.  The 
analysis  also  indicates  that  along  with  material  and  crack  growth  properties,  crack 
growth  rates  and  critical  crack  sizes  need  to  also  be  determined  and  incorporated  into 
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the  model  [54],  The  findings  of  this  investigation  were  carefully  considered  during  the 
development  of  this  thesis. 

2.1  Background  on  Systems  Engineering  Process 

Buede  states  “engineering  involves  the  practice  of  applying  scientific  theories 
to  the  development,  production,  deployment,  training,  operation  and  maintenance, 
refinement,  and  retirement  of  a  system  or  product  and  its  parts”  [17].  Systems  engi¬ 
neering  discipline  is  focused  on  how  to  create  a  system  that  meets  or  exceeds  the  needs 
of  all  of  the  stakeholders  involved  over  the  life  cycle  of  the  system.  The  International 
Council  on  Systems  Engineering  defines  Systems  Engineering  as  “an  interdisciplinary 
approach  and  means  to  enable  the  realization  of  successful  systems  [3].”  The  stake¬ 
holders  of  the  system  determine  the  objectives  of  the  system  to  which  the  success 
of  the  system  is  measured.  These  objectives  usually  include  cost  (cheaper),  sched¬ 
ule  (faster),  and  technical  performance  (better).  The  systems  engineer’s  role  is  to 
minimize  the  problems  associated  with  resolving  these  conflicting  objectives. 

The  systems  engineer  can  use  different  methods  to  apply  the  interdisciplinary 
approach  for  the  design  and  integration  process  by  using  the  Vee  model.  The  Vee 
model  can  also  be  used  incrementally.  The  processes  are  iterative.  The  development 
of  the  system  can  produce  individual  subsets  that  are  eventually  expanded  until  the 
entire  system  is  fully  operational.  The  systems  engineering  Vee  model  starts  with 
understanding  the  user  requirements  to  develop  the  system  concept  and  validation 
plan  (Figure  1.3).  This  step  begins  the  requirements  decomposition  and  definition 
portion  of  the  model.  It  is  similar  to  peeling  an  onion  with  each  layer  revealing  the 
required  specifications  for  the  system.  Once  the  onion  is  fully  peeled,  the  next  step 
is  to  develop  the  system  performance  specifications,  system  requirements,  and  the 
system  validation  plan.  At  this  point,  the  systems  engineers  must  help  facilitate  the 
design  and  system  tradeoffs  due  to  the  complexity  of  the  issues  and  the  multitude  of 
stakeholders  involved.  The  systems  engineers  then  expand  the  performance  specifica¬ 
tions  into  the  configuration  items  (Cl)  and  design-to  specifications  and  establish  the 
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Cl  verification  plan.  At  this  point,  the  systems  engineer  works  with  the  discipline  (de¬ 
sign)  engineers  (e.g.,  electrical,  mechanical,  etc.)  to  evolve  the  design-to  specifications 
into  build-to  documentation  and  inspection  plan.  By  isolating  design  decisions  using 
logical  engineering  principles  to  decrease  development  costs,  the  systems  engineer  can 
justify  spending  the  required  amount  of  money  to  incorporate  systems  engineering 
into  the  total  system  design  and  function  [17]. 

The  right-hand  side  of  the  Vee  depicts  the  integration  and  qualification  activi¬ 
ties  of  the  engineering  of  a  system.  Moving  up  this  side  of  the  Vee  begins  with  the 
fabrication,  assembly,  and  coding  to  the  build-to  documentation.  Integration  involves 
the  assembly  of  the  CIs  into  components,  the  assembly  of  lower-level  components  into 
higher-level  components,  and  the  assembly  of  high-level  components  into  the  system. 
This  involves  testing  (or  qualification)  of  the  newly  assembled  system  elements  to 
determine  whether  the  assembled  element  meets  the  set  of  requirements  or  specifica¬ 
tions  that  the  design  phase  had  established  for  that  element;  this  qualification  is  called 
verification.  Verification  addresses  the  following  question:  Did  we  build  the  system 
right?  Once  the  system  is  verified  against  the  system  requirements,  the  system  must 
be  validated.  Validation  answers  the  questions:  Did  we  build  the  right  system?  Or 
does  the  system  meet  the  user  requirements?  The  systems  engineer  must  demonstrate 
and  validate  the  system  to  the  user  validation  plan.  After  validation,  the  stakeholders 
determine  whether  the  system  is  acceptable  [17]. 

An  additional  systems’  engineering  model  that  can  be  used  is  the  waterfall 
model.  “The  waterfall  model  is  characterized  by  the  sequential  evolution  of  typical 
life-cycle  phases,  allowing  iteration  only  between  adjacent  phases  [17].”  However,  this 
model  has  a  major  problem  because  the  iteration  between  the  phases  is  often  too 
widely  separated.  The  final  model  for  systems  engineering,  which  is  primarily  used 
for  software  development,  is  the  spiral  model.  This  model  has  four  major  processes 
starting  with  design,  to  evaluation  and  risk  analysis,  followed  by  the  development  and 
testing,  with  the  final  step  being  planning  with  stakeholder  interaction  and  approval. 
The  number  of  iterations  of  the  spiral  process  can  vary.  The  spiral  model  can  also  be 
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used  as  a  basis  for  rapid  prototyping  to  produce  early,  partially  operational  prototypes. 
The  use  of  these  operational  prototypes  by  stakeholders  generates  new  and  improved 
requirements,  as  well  as  provides  the  stakeholders  with  increased  functionality  via 
early  releases  of  the  system  [17]. 

The  model  that  is  most  appropriate  for  the  ISHMS  is  the  Vee  model.  The  model 
encompasses  the  system’s  operational  concept  and  details  three  separate  architectures 
(functional,  physical,  and  operational).  “The  functional  and  physical  architectures  are 
developed  in  parallel  to  enhance  the  integration  of  them  into  the  operational  architec¬ 
ture  [17].”  The  functional  or  system  architecture  is  the  focus  of  this  thesis.  Once  the 
requirements  are  known,  the  functional  architecture  can  be  developed.  There  are  sev¬ 
eral  types  of  requirements  that  are  used  to  define  the  problem.  They  include  mission 
requirements,  originating  requirements,  and  derived  requirements.  Mission  require¬ 
ments  are  requirements  that  are  stated  in  terms  that  the  stakeholders  can  understand 
and  that  show  the  tradeoffs  between  doing  tasks  cheaper,  faster,  and/or  better.  The 
originating  requirements  are  requirements  that  are  focused  on  constraining  system 
characteristics  to  achieve  the  mission  requirements  [17].  These  requirements  are  es¬ 
tablished  by  the  stakeholders.  Systems  engineers  use  a  design  process  that  develops 
the  requirements  that  define  the  problem  while  balancing  the  dividing  the  physical 
resources  of  the  system  into  components  that  will  meet  the  requirements  by  perform¬ 
ing  certain  functions  to  solve  the  design  problem.  Systems  engineers  must  be  aware 
during  this  stage  how  each  decision  can  have  an  affect  on  the  performance  and  cost  of 
the  overall  system.  The  key  points  concerning  the  systems  engineering  design  process 
are: 

1.  Stakeholders  have  originating  requirements  that,  taken  together  address  every 
phase  of  the  system’s  life  cycle.  Capturing  the  complete  set  of  originating  re¬ 
quirements  ensures  a  concurrent  engineering  process. 

2.  The  set  of  originating  requirements  should  ensure  a  decision-rich  design  process 
by  not  over  constraining  the  design.  The  following  attributes  of  requirements 
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are  meant  to  ensure  the  process  is  not  overconstrained:  traced,  correct,  un¬ 
ambiguous,  understandable,  design  independent,  attainable,  comparable,  and 
consistent. 

3.  At  the  same  time  the  originating  requirements  should  not  underconstrain  the 
design  because  the  stakeholders  should  be  happy  with  the  system  that  is  created. 
Complete,  verifiable,  and  traceable  requirements  should  guarantee  this  [17]. 

Finally,  the  derived  requirements  are  even  more  constraining  but  are  developed 
from  establishing  the  system  specifications.  “Requirements  are  the  cornerstone  of 
the  systems  engineering  process  [17].”  This  is  because  requirements  define  the  design 
problem.  Having  accurate  and  good  requirements  are  crucial  to  producing  a  successful 
system  that  meets  the  stakeholders’  needs. 

The  next  step  in  the  systems  engineering  process  is  to  define  the  operational 
concept.  “The  operational  concept  of  the  system  provides  the  theme  for  the  system  as 
viewed  by  the  stakeholders  and  defines  scenarios  depicting  how  its  users  will  employ 
the  system  and  how  the  system  will  interact  with  other  systems  [17].”  The  operational 
concept  for  this  thesis  is  to  develop  an  ISHMS  for  any  aging  aircraft.  ISHMS  is  de¬ 
fined  as  an  integrated  monitoring  system  that  is  incorporated  into  the  overall  aircraft 
systems  (e.g.,  electrical,  mechanical,  etc.)  to  determine  the  overall  structural  health 
of  the  system  by  detecting  any  anomalies  in  the  critical  fatigue  structural  areas  of  the 
aircraft  while  maintaining  or  increasing  the  level  of  safety  of  flight.  This  system  will 
be  cost-effective  and  provide  real-time  data  to  the  pilots  and  maintainers  for  analysis. 

An  external  systems  diagram  must  be  developed  to  show  the  interaction  between 
the  inputs  and  controls  that  enter  the  system,  as  well  as  outputs  that  the  system  pro¬ 
duces,  and  the  mechanisms  that  are  used  to  transform  the  inputs  into  the  outputs. 
Systems  engineers  must  also  concern  themselves  with  the  systems  relevant  to  every 
stage  in  the  life  cycle  of  the  system  throughout  the  entire  development  process.  After 
developing  an  external  systems  diagram,  an  objectives  hierarchy  of  the  system  must 
be  developed  to  determine  the  criteria  that  the  stakeholders  will  measure  their  satis- 
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faction  of  the  system  performance,  cost,  and  development  schedule.  Ultimately,  the 
systems  engineers  must  work  with  the  stakeholders  to  conduct  performance,  cost,  and 
cost-performance  trade-off  studies.  The  final  step  of  integration  and  qualification  is 
acceptance  by  the  stakeholders.  The  stakeholders  compare  the  system  to  their  needs 
and  decide  if  they  will  accept  the  system  as  is  or  if  changes  will  need  to  be  made.  The 
completion  of  this  phase  indicates  that  there  is  at  least  one  feasible  solution  that  will 
satisfy  the  stakeholders’  needs  and  is  verified  and  approved  by  the  stakeholders  [17]. 
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III.  Methodology 


Figure  3.1:  Chapter  3  Decomposition 


In  this  chapter  (Figure  3.1)  the  methodology  used  in  order  to  deal  with  the 
problem  of  this  thesis  is  discussed.  The  scoping  of  the  problem  is  explained  and 
the  basic  assumptions  detailed.  The  steps  of  the  system  engineering  methodology  are 
discussed  and  the  methods  to  define  the  stakeholders’  perspective  and  the  operational 
concept  are  presented.  The  development  of  the  system  requirements  and  the  various 
architectural  products  is  analyzed.  The  chapter  concludes  with  a  detailed  explanation 
of  the  material  analysis  and  crack  growth  modeling  used  in  the  simulations  which 
helped  to  show  the  potential  benefit  of  an  ISHMS. 
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Figure  3.2:  Problem  Scope 
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Figure  3.3:  Problem  Definition 
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3.1  Scope  and  Assumptions 

3.1.1  Scope.  In  order  to  develop  a  systems  engineering  approach  to  es¬ 
tablishing  an  ISHMS  that  can  be  applied  to  any  aging  aircraft,  the  thesis  had  to 
be  adequately  scoped  to  provide  a  realistic  example.  SAF /IARL  originally  contacted 
AFIT /ENY  to  request  a  thesis  be  accomplished  to  determine  how  real-time  integrated 
health  monitoring  could  be  accomplished  for  the  aging  A-37  aircraft  used  by  CAF.  The 
thesis  proposal  stated  that  these  CAF  A-37  aircraft  have  very  high  flight  hours  and 
are  approaching  or  have  already  exceeded  the  originally  designed  service  life.  Their 
primary  concern  came  from  finding  structural  cracks  during  scheduled  inspections. 
However,  there  is  no  current  system  on  the  CAF  aircraft  that  could  detect  new  cracks 
on  the  structure  or  detect  if  the  current  cracks,  which  are  within  acceptable  limits, 
grow.  The  original  goal  of  the  thesis  proposal  was  to  develop  a  systems  engineering 
approach  to  design  a  system  that  would  monitor  the  structural  health  of  the  CAF 
A-37  airframe.  By  developing  and  implementing  a  monitoring  system,  the  CAF  air 
forces  aim  was  to  reduce  or  eliminate  extensive  inspections  and  safely  extend  the  orig¬ 
inal  designed  service  life.  However,  when  the  thesis  team  tried  to  obtain  maintenance 
history  on  these  CAF  A-37  aircraft,  the  team  found  that  the  necessary  maintenance 
data  was  not  available.  Therefore,  the  thesis  sponsor  suggested  contacting  the  Ma¬ 
ture  And  Proven  Aircraft  (MAPA)  division  at  Hill  Air  Force  Base,  Utah  to  obtain 
the  data  on  the  top  10  locations  on  the  A-37  aircraft  identified  as  showing  signs  of 
critical  fatigue.  The  MAPA  division  had  assessed  critical  structural  nodes,  otherwise 
known  as  FCLs,  over  the  entire  aircraft  to  determine  which  locations  needed  to  be 
monitored  to  maintain  the  same  safety  of  flight  standards  after  the  aircraft  passed 
its  designed  service  life  limit.  To  scope  this  thesis  to  an  achievable  goal,  the  thesis 
team  narrowed  its  focus  to  developing  a  systems  engineering  approach  to  designing 
an  ISHMS  for  any  aging  aircraft  but  using  the  A-37  aircraft  data  provided  by  MAPA 
to  determine  the  FCLs.  The  ISHMS  team  chose  to  analyze  the  number  one  FCL. 

The  sponsor  also  requested  cost  estimates  for  installing  a  real-time,  integrated 
structural  health  monitoring  system.  Another  aspect  of  scoping  the  problem  was  to 
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determine  that  only  the  user  of  the  system  could  determine  the  definition  of  real¬ 
time  and  that  the  team  would  incorporate  the  request  in  the  user’s  requirements  of 
the  systems  engineering  process  for  an  ISHMS  that  is  developed.  The  sponsor  also 
requested  cost  estimates  for  installing  a  monitoring  system.  The  ISHMS  thesis  team 
concluded  that  it  does  not  have  the  expertise  to  establish  specific  cost  estimates  for 
developing,  designing,  and  installing  an  ISHMS.  It  is  not  the  responsibility  of  the 
systems  engineer  to  determine  costs,  instead  it  is  his/her  responsibility  to  work  with 
the  design  engineers  to  meet  the  user  requirements  and  therefore  eventually  the  cost 
estimates  will  be  available.  The  ISHMS  thesis  team  does  have  limited  expertise  in 
certain  areas.  Three  team  members  are  experienced  Aircraft  Maintenance  Officers, 
two  members  are  mechanical  engineers,  one  member  is  an  aeronautical  engineer,  and 
one  member  is  an  electrical  engineer. 

Over  the  period  of  the  thesis,  the  primary  individual  sponsor  moved  to  a  different 
job  and  the  team  could  not  fold  an  additional  sponsor  that  would  fund  the  original 
request.  Another  limitation  of  this  thesis  was  the  time  that  was  available  to  conduct 
the  data  collection,  analyze  the  data  for  the  FCLs,  and  develop  a  systems  engineering 
approach  that  can  be  applied  to  all  types  of  aging  aircraft.  Due  to  the  limitations  of 
losing  our  sponsor,  our  advisors  took  an  active  role  in  guiding  and  focusing  the  team. 

3.1.2  Assumptions.  There  are  a  number  of  assumptions  that  were  required 
to  develop  the  systems  engineering  process  to  develop  an  ISHMS.  They  are: 

•  Appropriate  technology  has  already  been  developed  to  monitor  all  of  the  FCLs. 

•  Equipment  can  be  developed  to  capture  the  data  from  the  sensors  on  the  FCLs 

•  Enough  maintenance  history  data  will  be  available  on  any  aging  aircraft  that 
an  ISHMS  will  be  implemented 

•  The  total  life-cycle  cost  of  the  system  is  lower  than  the  current  maintenance 
practices 

•  The  ISHMS  will  maintain  or  increase  the  SOF  for  that  specific  aircraft. 
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•  Installation  of  the  monitors  on  the  FCLs  will  not  cause  additional  damage 

•  Maintenance  technicians  can  be  trained  to  download  and  analyze  the  mainte¬ 
nance  data 

The  methodology  used  to  define  the  system’s  stakeholders  is  described  in  the 
next  section.  Also,  the  methodology  used  to  develop  the  system’s  operational  concept 
is  discussed. 

3.2  Stakeholder’s  Perspective  of  the  System 

An  important  step  at  the  beginning  of  the  design  of  a  system  using  the  Systems 
Engineering  methodology  is  to  identify  the  stakeholders.  As  it  is  stated  in  the  relevant 
literature  the  more  generic  term  stakeholders  is  preferred  over  the  term  users  because 
the  term  can  describe  multiple  categories  of  users. 

Some  of  the  users  categories  are  the  bill  payers,  the  developers,  the  operators, 
the  trainers  etc.  Each  of  these  categories  is  involved  in  different  ways  at  different 
phases  of  the  system’s  life-cycle,  so  the  use  of  term  stakeholders  can  better  describe 
these  differences  than  the  term  user. 

As  a  result  of  the  different  ways  the  various  stakeholders  are  involved  in  the 
systems  life  cycle,  each  stakeholder  has  his  own  understanding  and  view  of  the  sys¬ 
tem.  Depending  on  his/her  role,  the  perception  of  the  system  design,  development, 
production,  use,  maintenance,  retirement  may  differ  significantly  from  the  other  stake¬ 
holders. 

According  to  the  systems  engineering  methodology  it  is  important  for  the  sys¬ 
tems  engineer  to  identify  (early  in  the  process)  all  the  stakeholders  involved  with  the 
system  under  development.  It  is  also  important  that  the  engineer  work  with  those 
stakeholders  and  get  a  thorough  understanding  of  each  ones  perspective  and  require¬ 
ments.  The  importance  of  these  actions  lies  in  the  fact  that  all  stakeholders’  views 
and  requirements  are  equally  significant.  There  are  not  views  and  requirements  that 
are  right  or  wrong  and  the  perspective  and  requirements  of  a  specific  stakeholder  are 
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not  more  significant  than  another’s.  If  the  stakeholders  are  not  properly  defined  some 
requirements  for  a  phase  of  the  life  cycle  may  not  be  addressed  during  the  design. 
This  will  result  in  an  incomplete  design. 

It  is  the  systems  engineer’s  role  to  work  with  all  the  stakeholders  and  based 
upon  their  inputs  to  establish  priorities,  and  to  specify  the  final  product’s  design: 
the  one  that  will  satisfy  all  mandatory  requirements  and  will  address  as  many  of  the 
stakeholders’  views  as  possible. 

In  order  to  identify  the  stakeholders  a  critical  question  that  must  be  answered 
is  who  has  the  right  to  have  a  requirement  for  the  system?  [17].  Based  on  the  answer 
to  the  above  question  a  system  requirements  team  comprised  of  the  systems  engineers 
and  representatives  of  all  the  stakeholders  categories  is  formed.  Their  goal  is  to  derive 
the  operational  concept  and  the  originating  requirements. 

For  the  purpose  of  this  thesis,  the  group  members  and  the  academic  advisors 
decided  to  have  both  the  roles  of  the  systems  engineers,  who  are  supposed  to  identify 
all  the  stakeholders  and  form  the  system  requirements  team,  and  of  the  stakeholders, 
who  are  supposed  to  provide  the  systems  engineers  with  their  operational  needs  and 
their  requirements.  The  factors  that  led  this  team  to  this  decision  were:  the  available 
time  for  the  elaboration  of  this  thesis,  the  lack  of  specified  stakeholders  to  work  with 
and  the  need  to  have  a  wider  and  more  flexible  scope  for  our  problem.  All  these 
factors  were  critical  in  conjunction  with  each  other.  The  thesis  team  had  to  keep  the 
scope  of  our  problem  wide  and  flexible  enough  so  that  the  thesis  would  be  able  to 
show  the  applicability  of  the  systems  engineering  methodology  to  the  design  of  the 
ISHMS.  In  order  to  achieve  this  goal  the  thesis  had  to  define  the  stakeholders’  needs 
and  requirements  that  would  be  used  as  a  basis  for  the  development  of  the  system’s 
architecture.  All  that  had  to  be  accomplished  within  a  specified  period  of  time  and 
with  additional  constraints  as  to  the  availability  of  the  team  members. 

The  group  members  felt  that  the  most  appropriate  way  to  achieve  the  thesis 
goals  given  the  above  constraints  would  be  to  create  a  list  of  the  ISHMS  life-cycle 
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phases  and  try  to  identify  the  stakeholders  for  each  phase.  This  identification  of 
potential  stakeholders  was  based  on  the  diverse  professional  experience  of  the  group 
members.  Also,  based  on  the  same  experience  and  knowledge,  the  group  members 
tried  to  understand  and  describe  each  of  the  stakeholder’s  view  and  requirements.  The 
final  product,  which  is  a  set  of  assumptions,  has  not  been  validated,  and  restricted 
the  development  of  the  originating  requirements  document. 

3.3  Operational  Concept  of  the  System 

The  development  of  the  operational  concept  is  another  essential  step  in  the  sys¬ 
tems  engineering  process.  By  the  term  operational  concept  a  description  of  the  way 
the  system  will  be  utilized  is  implied.  In  this  description  of  the  system’s  utilization, 
a  vision  of  the  system,  its  interactions  with  external  systems  and  the  main  functions 
of  the  system  are  included.  An  important  aspect  of  the  operational  concept  is  that 
it  represents  the  agreement  between  the  various  stakeholders  about  the  use  of  the 
system  and  the  needs  it  is  going  to  serve.  Usually  the  operational  concept  is  written 
in  the  stakeholders’  informal  language.  It  is  the  systems  engineers’  role  to  bring  the 
stakeholders  to  this  agreement  and  produce  the  operational  concept.  The  understand¬ 
ing  of  each  stakeholder’s  vision  for  the  system  and  the  system’s  mission  requirements 
are  essential. 

In  order  to  define  the  operational  concept  there  are  several  methods  the  systems 
engineers  can  apply: 

•  A  set  of  scenarios  that  describe  the  inputs  to  the  system  and  the  produced  out¬ 
puts  at  the  various  phases  of  the  life  cycle,  is  one  way  to  develop  the  operational 
concept.  In  these  scenarios,  the  system  is  treated  as  a  black  box.  That  means 
that  only  the  inputs  and  outputs  of  the  system  are  shown;  the  transformation 
that  occurs  within  the  system  is  not  visible.  This  allows  the  operational  con¬ 
cept  not  to  influence  and  steer  the  system’s  design.  In  each  scenario  the  view 
of  a  stakeholder  about  the  production,  use  and  maintenance  of  the  system  is 
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shown.  The  scenarios  are  developed  separately  for  each  life-cycle  phase  and  are 
as  many  as  to  address  all  stakeholders  groups  that  are  involved  in  the  specific 
phase.  These  sets  of  scenarios  describe  the  reason  for  the  system’s  existence  and 
result  in  the  development  of  an  operational  concept  for  each  life-cycle  phase. 

•  A  variation  of  the  above  method  is  the  method  described  by  Hunger  [17].  The 
term  mission  analysis  is  used  by  Hunger  instead  of  the  term  operational  concept 
and  the  scenarios  are  called  missions.  The  life-cycle  phases  of  the  system  are 
divided  into  operational  and  non-operational  phases  for  which  sortie  and  life 
missions  are  generated  respectively.  Missions  are  developed  for  each  life-cycle 
phase  while  some  scenarios  may  extend  to  more  than  one  phases.  These  mis¬ 
sions  provide  information  about  the  system’s  interaction  with  other  systems  and 
define  the  system’s  boundaries. 

•  Another  method  that  can  be  used  to  produce  the  operational  concept  is  the  de¬ 
velopment  of  use  cases.  The  concept  of  use  cases  is  more  related  to  the  software 
engineering,  but  there  is  no  limitation  to  their  use  in  systems  engineering.  The 
use  cases  are  similar  to  the  sets  of  scenarios  but  are  differently  structured  than 
the  scenarios.  The  main  difference  is  that  the  use  cases  are  developed  using 
a  specific  goal  as  a  basis.  Variations  in  the  use  cases  around  that  basis  help 
describe  the  different  views  of  the  stakeholders.  The  use  cases  can  then  be  used 
in  the  derivation  of  requirements. 

•  The  input-output  trace  modeling  technique  can  also  be  used  in  the  development 
of  the  operational  concept.  The  model  produced  from  this  technique  consists 
of  a  vertical  time  line  for  each  system  involved  in  the  scenario.  Horizontal  arcs 
starting  from  the  originating  system  and  ending  at  the  receiving  system  depict 
the  systems  interactions.  These  models  are  focused  on  time  based  interactions 
between  the  systems.  Their  advantage  over  the  written  scenarios  is  that  they 
provide  a  visualization  of  the  sequence  of  actions  which  can  be  more  helpful 
during  the  system  design. 
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•  Using  the  same  concept  as  the  input-output  trace  model  the  sequence  diagrams 
provide  another  modeling  option  that  can  be  used  in  the  development  of  the 
operational  concept.  The  sequence  diagrams  used  in  the  Unified  Modeling  Lan¬ 
guage  (UML)  have  a  lot  more  complexity  than  the  input-output  trace  diagrams 
but  are  also  more  explicit. 

In  order  to  develop  the  operational  concept,  the  thesis  group  decided  to  create 
sets  of  scenarios  for  the  life-cycle  phases  of  the  system.  The  scenarios  are  developed 
with  the  key  stakeholder  for  each  phase  as  the  main  actor.  The  other  stakeholders 
are  also  included  in  the  scenario  as  needed  while  other  constraining  and  complexity 
factors  are  added  in  the  scenario.  Another  reason  for  the  selection  of  this  method  is 
that,  according  to  the  thesis  group  members’  understanding,  the  sequence  diagrams, 
the  input-output  model  and  the  use  cases  would  require  a  greater  involvement  of  the 
stakeholders.  Therefore  the  creation  of  scenarios  seemed  more  suitable.  Some  aspects 
that  the  thesis’  methodology  was  not  able  to  achieve  are  the  validation  of  the  scenarios 
and  the  agreement  between  the  stakeholders  aspect  of  the  operational  concept. 

In  the  next  section,  the  development  of  the  systems  requirements  is  discussed. 
The  assumptions  made  by  the  thesis  group,  and  the  detailed  steps  of  the  selected 
approach  are  analyzed. 

3.4  Requirements  Development 

Manpower  intensive  periodic  maintenance  inspections  were  driving  up  the  cost 
of  operating  legacy  aircraft.  An  ISHMS  was  proposed  as  a  solution  to  reducing  the 
cost  of  legacy  aircraft  operations.  The  constraints  imposed  on  the  design  space  were: 

1.  Legacy  aircraft  use  would  continue  at  its  current  pace 

2.  ISHMS  would  be  retrofitted  to  the  legacy  aircraft 

3.  Current  SOF  would  be  maintained 

The  effective  impact  of  the  constrained  design  space  was  to  bypass  the  initial 
business  case  in  favor  of  monitoring  (versus  repair  or  replace)  the  legacy  aircraft. 
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This  was  the  starting  point  for  a  systems  engineering  approach  to  the  development  of 
an  ISHMS.  The  ISHMS  development  process  began  with  the  requirements  definition. 
The  requirements  definition  was  the  baseline  with  the  final  system  was  compared  with 
to  determine  if  a  successful  design  was  created.  Requirements  were  the  cornerstone  of 
the  systems  engineering  process  and  the  focal  point  of  the  ISHMS  development  [17]. 
Many  of  the  requirements  resulted  from  working  within  the  physical  constraints  of 
the  legacy  aircraft.  The  SE  creation  of  an  ISHMS  on  a  legacy  aircraft  design  yielded 
a  less  streamlined  and  integrated  solution  than  would  be  possible  with  a  new  aircraft 
design.  All  phases  of  the  ISHM  system  life-cycle  were  addressed  (Figure  3.4). 


Figure  3.4:  Originating  Requirements  Development  Summary  [17] 


Assumptions  were  made  to  quantify  the  current  aircraft  flight  profile,  current 
maintenance  inspection  costs,  and  to  estimate  installation  costs.  Flight  data  recorder 
information  was  not  available;  therefore,  a  general  fighter  flight  spectrum  was  used. 
The  baseline  inspect  and  fix  scenario  was  compared  to  the  ISHMS  modified  scenario  to 
show  improvement  in  operating  cost.  The  ISHMS  team  had  limited  sponsor  feedback, 
thus  based  upon  field  experience  team  members  served  as  stakeholders  to  clarify 
the  initial  requirements  as  well  as  the  SE  to  refine  the  requirements.  There  were 
many  stakeholders  across  the  ISHMS  life-cycle  phases,  but  the  primary  stakeholders 
referenced  were:  HQ  AF,  pilots,  maintainers,  and  acquisition  personnel. 
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The  method  for  creating  the  ISHMS  requirements  involved  a  seven  step  ap¬ 
proach: 

1.  The  first  step  consisted  of  developing  the  operational  concept.  The  operational 
concept  created  a  general  vision  of  the  system,  a  statement  of  capability  (or 
mission)  requirements,  and  how  the  system  was  expected  to  be  used.  The 
operational  concept  was  given  by  the  sponsor. 

2.  The  second  step  was  the  definition  of  the  system  boundary  with  an  external 
systems  diagram  (Figure  3.5). 


Figure  3.5:  Context  Diagram  [17] 

3.  The  third  step  was  the  development  of  the  weighted  objectives  hierarchy.  This 
hierarchy  defined  cost,  schedule,  and  performance  goals  that  the  stakeholders 
required  for  an  acceptable  system  design  (Figure  3.6). 

4.  The  fourth  step  of  developing,  analyzing  and  refining  the  requirements  required 
taking  the  operational  concept,  system  inputs  and  outputs,  and  combined  with 
the  objectives  hierarchy  to  refine  the  originating  requirements  into  the  system 
requirements. 
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Figure  3.6:  Objectives  Hierarchy  Example  [17] 
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5.  The  fifth  step  was  to  ensure  the  requirements  feasibility.  Feasibility  was  deter¬ 
mined  if  the  requirement  was  verifiable  with  physics-based  modeling,  consistent 
with  general  maintenance  practices,  or  testable. 

6.  The  sixth  step  was  defining  the  qualification  system  requirements.  The  system 
qualification  involved  establishing  the  requirements  to;  validate  the  operational 
concept,  verify  the  components  &  system,  validate  the  system,  and  accept  the 
system.  Extensive  structural  modeling  and  simulation  was  conducted  of  the 
A-37  aircraft  to  qualify  the  system  requirements  (Figure  3.7). 

7.  The  seventh  and  final  step  was  obtaining  the  sponsor  approval  of  the  require¬ 
ments. 

The  Buede  process  of  establishing  the  ISHMS  requirements  was  chosen  because 
of  its  structured  method  [17].  This  structured  approach  was  a  consistent  method  for 
both  the  originating  and  derived  requirements.  Finally,  the  structured  requirements 
method  was  compatible  with  the  chosen  Vee  Model  of  SE  design.  In  accordance 
with  the  Vee  model,  system  requirements  became  more  specific  as  the  development 
process  progressed.  The  ISHMS  requirements  were  specified  down  to  the  third  level 
of  the  requirements  pyramid  (Figure  3.8).  This  meant  the  mission,  originating,  and 
system  level  requirements  were  developed.  The  ISHMS  team  decided  to  stop  the 
requirements  specification  before  the  subsystem  and  component  level.  The  subsystem 
and  component  level  was  chosen  as  the  line  of  demarcation  because  this  was  the  point 
where  dedicated  engineering  specialists  provide  the  engineering  expertise  necessary  to 
establish  detailed  requirements.  Attempts  to  establish  the  component  specifications 
will  unnecessarily  limit  the  design  space. 

The  requirements  process  began  with  the  mission  and  originating  requirements. 
These  requirements  were  the  starting  point  of  the  ISHMS  written  by  the  user.  The 
user  input  was  a  capability  needs  document  listing  a  need  for  an  ISHMS  to  operate 
legacy  aircraft  beyond  their  original  design  service  life.  Ideally,  these  originating  re¬ 
quirements  were  design  independent.  In  reality,  the  initial  business  case  was  assumed 
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Figure  3.7:  Structural  Simulation  Steps 


63 


Mission  Requirements 


Requirements 


Component 

Requirements 


System 

Requirements 


Cl 


V  Derived 
Requirements 


Figure  3.8:  Requirements  Hierarchy  [17] 


already  completed  with  the  result  of  modifying  a  legacy  aircraft  with  an  ISHMS  as 
the  result.  This  jump  to  an  ISHMS  as  the  solution  to  increasing  maintenance  in¬ 
spection  requirements  had  an  effect  of  constraining  the  design  space  automatically 
reducing  options  such  as;  maintaining  the  status  quo,  using  automated  inspections, 
or  replacing  the  wing  on  the  legacy  aircraft.  The  initial  scoping  of  the  design  made 
the  benefit  analysis  very  important  to  determining  if  installing  an  ISHMS  yielded  an 
economic  benefit. 

The  design  requirements  allowed  the  SE  development  team  to  apply  a  level  of 
engineering  rigor  to  the  originating  requirements.  The  design  requirements  partitioned 
the  design  problem.  The  partitioning  of  the  design  problem  enabled  the  establishment 
of  a  verification  and  validation  plan.  The  design  requirements  were  clarified  with  the 
stakeholders  and  trade-space  was  established. 

3.5  System  Qualification  First  Look 

Before  beginning  preliminary  design,  system  engineers  should  consider  how  the 
system  requirements  will  be  verified.  This  thesis  analyzed  each  system  requirement 
and  briefly  detailed  how  each  would  be  tested  or  verified  for  qualification.  The  analysis 
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done  for  this  thesis  does  not  constitute  a  full-up  qualification  or  verification  test 
plan.  The  analysis  assisted  in  showing  requirements  feasibility  and  could  assist  others 
following  the  systems  engineering  process  presented  here  with  preparations  for  their 
own  qualification  testing. 

Verification  of  requirements  can  generally  occur  through  four  types  of  methods: 
inspection,  analysis  and  simulation,  instrumented  test,  and  demonstration.  This  the¬ 
sis  selected  the  appropriate  method  for  each  requirement.  Of  course,  this  analysis 
occurred  prior  to  design  which  does  not  allow  for  tailoring  testing  toward  the  specifics 
of  the  system.  As  stated,  the  initial  qualification  review  would  be  revised  after  system 
design  to  best  test  and  verify  the  system  as  designed. 

The  architectural  framework  and  the  architecture  building  process  are  discussed 
in  the  next  section.  The  methodology  for  selecting  which  architectural  products,  and 
how  they  will  be  developed  is  analyzed.  Also,  assumptions,  tools  and  the  rationale 
for  this  selection  are  discussed. 

3. 6  Architectures 

Aircraft  come  in  various  shapes  and  configurations  which  are  mostly  determined 
by  the  intended  role  or  roles  of  the  aircraft.  However,  all  aircraft  have  at  least  one 
thing  in  common  and  that  is  an  intrinsic  complexity  which  is  carried  through  all  of 
the  life-cycle  stages  (i.e.,  development,  production,  operations  &  maintenance,  and 
retirement).  This  complexity  not  only  comes  from  the  thousands  of  components 
and  specialized  parts  that  must  work  together  for  the  aircraft  to  function  properly, 
but  also  from  the  various  external  systems  that  are  needed  to  support  the  aircraft 
operations.  Examples  of  external  systems  include  personnel,  tools,  equipment,  and 
other  support  systems,  for  instance  global  positioning  system  (GPS)  satellites  for 
navigation  purposes.  In  the  midst  of  this  complexity,  the  systems  engineer  is  expected 
to  provide  clarity  and  simplicity  needed  for  efficient  and  effective  decision-making. 
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The  necessity  for  understanding  and  dealing  with  complex  system  interactions 
is  particularly  applicable  to  USAF  aircraft  because  a  single  decision  may  have  far- 
reaching  implications  into  multiple  systems  and  organizations.  Often  times,  system 
engineers  use  architectures  as  one  of  the  preferred  SE  means  of  providing  clarity  and 
simplicity  to  complex  systems.  Architectures,  as  defined  in  SE,  are  graphical,  textual, 
or  tabular  representations  which  are  used  to  display  information  about  a  system  in  a 
comprehensive  way  that  facilitates  decision-making  [26] .  The  goal  of  this  section  is  to 
explain  how  system  architectures  were  used  to  model  the  potential  development  and 
integration  of  a  hypothetical  ISHMS  into  an  aging  aircraft.  In  addition,  this  thesis 
will  also  explain  the  reasons  for  choosing  specific  architecture  products  as  well  as  the 
guidelines  used  for  the  development  of  the  architectures. 

System  architectures  come  in  different  shapes,  forms,  and  perspectives  based 
on  the  team’s  decisions  and  on  the  personal  preferences  of  the  architect.  However, 
even  though  this  flexibility  in  creating  system  architectures  may  promote  innovation, 
it  also  has  the  potential  to  further  confuse  the  decision-makers  that  generally  come 
from  different  backgrounds.  Fortunately,  the  DoD  realized  that  lack  of  architectures 
standardization  may  lead  to  miscommunication,  or  even  worse,  lack  of  communication 
between  stakeholders  and  developers.  As  a  result,  the  DoD  generated  a  standardized 
solution  which  is  now  known  as  the  DoD  Architecture  Framework  (DoDAF).  The 
DoDAF,  along  with  several  other  documents,  provide  guidelines  and  policies  for  the 
development  of  system  architectures  within  the  DoD  and  is  the  source  document  for 
the  development  of  the  architectural  products. 

3.6.1  DoD  Architecture  Framework.  According  to  the  DoDAF,  an  inte¬ 
grated  architecture  is  usually  described  in  terms  of  three  views:  Operational  View 
(OV),  Systems  View  (SV),  and  Technical  Standards  View  (TV).  Together,  these  ar¬ 
chitectural  views  provide  an  organized  and  systematic  way  to  gain  understanding, 
support  analysis,  provide  logic  for  potential  changes,  specify  requirements,  or  support 
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systems  level  design  and  integration  activities.  The  following  paragraph  provides  a 
brief  description  of  each  of  the  views. 

The  OV  contains  graphical  and  textual  descriptions  of  operational  activities, 
or  functions,  and  information  exchanges  [26].  Similarly,  the  SV  also  uses  graphical 
and  textual  products;  however,  the  emphasis  is  placed  on  describing  actual  systems 
components  and  interconnections  in  support  of  the  functions  or  capabilities  described 
in  the  OV.  The  TV  is  defined  as  the  minimal  set  of  rules  governing  the  arrangement, 
interaction,  and  interdependence  of  systems  parts  or  elements.  The  purpose  of  the 
TV  is  to  ensure  that  a  system  satisfies  engineering  specifications.  Furthermore,  the 
DoDAF  also  identifies  the  All  Views  (AV)  products  which  provide  information  relevant 
to  the  entire  architecture  but  do  not  represent  a  distinct  view  of  the  architecture  [26]. 
Each  of  these  views  has  a  myriad  of  products  from  which  the  systems  architects  can 
choose  from.  Table  3.1  lists  each  of  those  products. 

3.6.2  Architecture  Building  Process.  The  DoDAF  provides  a  generic  six- 
step  process  (Figure  3.9)  of  building  an  architecture  description  that  was  used  by  the 
team.  The  first  step  was  to  determine  the  intended  use  of  the  architecture.  In  the  case 
of  the  ISHMS  for  aging  aircraft,  there  were  two  fundamental  purposes  for  creating 
an  architecture  description.  One  of  the  purposes  was  to  try  to  identify  as  clearly  as 
possible  the  overall  requirements  that  should  bound  the  development  of  the  ISHMS. 
The  second  purpose  was  to  support  an  investment  decision  as  to  whether  or  not 
the  development  of  an  ISHMS  for  an  aging  aircraft  makes  financial  sense.  Since  the 
target  aircraft  was  the  A-37  owned  by  the  CAF,  the  thesis  team  wanted  to  interview 
their  personnel  in  order  to  gain  insight  of  the  actual  user  requirements.  In  addition, 
the  team  had  hoped  to  gain  a  better  understanding  of  their  maintenance  procedures 
and  their  flight  profiles  among  other  things  which  would  greatly  influence  the  final 
ISHMS  design.  However,  the  thesis  team  did  not  have  access  to  the  CAF  and  as 
such  the  thesis  team  had  to  collect  the  requirements  from  the  group’s  knowledge  and 
experience. 
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Table  3.1:  Architecture  products  defined  in  the  DoDAF  [27] 


Applicable 

View 

Framework 

Product 

Framework  Product  Name 

General  Description 

All  Views 

AV-1 

Overview 

and  Summary  Information 

Scope,  purpose,  intended  users,  environment  depicted, 
analytical  findings 

All  Views 

AV-2 

Integrated  Dictionary 

Architecture  data  repository  with  definitions 
of  all  terms  used  in  all  products 

Operational 

OV-1 

High-Level  Operational 

Concept  Graphic 

High-level  graphical/textual  description  of 

operational  concept 

Operational 

OV-2 

Operational  Node  Connectivity 

Description 

Operational  nodes,  connectivity,  and  information 
exchange  needlines  between  nodes 

Operational 

OV-3 

Operational  Information 

Exchange  Matrix 

Information  exchanged  between  nodes  and  the 
relevant  attributes  of  that  exchange 

Operational 

OV-4 

Organizational  Relationships 
Chart 

Organizational,  role,  or  other  relationships 
among  organizations 

Operational 

OV-5 

Operational  Activity  Model 

Capabilities,  operational  activities,  relationships  among 
activities,  inputs,  and  outputs;  overlays  can  show  cost, 
performing  nodes,  or  other  pertinent  information 

Operational 

OV-6a 

Operational  Rules  Model 

One  of  three  products  used  to  describe  operational  activity 
identifies  business  rules  that  constrain  the  operation 

Operational 

OV-6b 

Operational  State  Transition 
Description 

One  of  three  products  used  to  describe  operational  activity 
identifies  business  process  responses  to  events 

Operational 

OV-6c 

Operational  Event-Trace 
Description 

One  of  three  products  used  to  describe  operational  activity 
traces  actions  in  a  scenario  or  sequence  of  events 

Operational 

OV-7 

Logical  Data  Model 

Documentation  of  the  system  data  requirements  and  structural 
business  process  rules  of  the  Operational  View 

Systems 

SV-1 

Systems  Interface 

Description 

Identification  of  system  nodes,  systems,  and  system  items 
and  their  interconnections,  within  and  between  nodes 

Systems 

SV-2 

Systems  Communications 

Description 

System  nodes,  systems,  and  system  items,  and  their 

related  communications  lay-downs 

Systems 

SV-3 

Systems-Systems  Matrix 

Relationships  among  systems  in  a  given  architecture;  can  be 
designed  to  show  relationships  of  interest,  e.g.,  system- type 
interfaces,  planned  vs.  existing  interfaces,  etc. 

Systems 

SV-4 

Systems  Functionality 

Description 

Functions  performed  by  systems  and  the  system  data  flows 
among  system  functions 

Systems 

SV-5 

Operational  Activity  to  Systems 
Function  Traceability  Matrix 

Mapping  of  systems  back  to  capabilities  or  of  system  functions 
back  to  operational  activities 

Systems 

SV-6 

Systems  Data  Exchange 

Matrix 

Provides  details  of  system  data  elements  being  exchanged 
between  systems  and  the  attributes  of  that  exchange 

Systems 

SV-7 

Systems  Performance 

Parameters  Matrix 

Performance  characteristics  of  Systems  View  elements  for 
the  appropriate  time  frame(s) 

Systems 

SV-8 

Systems  Evolution 

Description 

Planned  incremental  steps  toward  migrating  a  suite  of  systems 
to  a  more  efficient  suite,  or  toward  evolving  a  current  system  to 
a  future  implementation 

Systems 

SV-9 

Systems  Technology 

Forecast 

Emerging  technologies  and  software/hardware  products  that 
are  expected  to  be  available  in  a  given  set  of  time  frames  and 
that  will  affect  future  development  of  the  architecture 

Systems 

SV-lOa 

Systems  Rules  Model 

One  of  three  products  used  to  describe  system  functionality; 
identifies  constraints  that  are  imposed  on  systems  functionality 
due  to  some  aspect  of  systems  design  or  implementation 

Systems 

SV-1  Ob 

Systems  State  Transition 
Description 

One  of  three  products  used  to  describe  system  functionality; 
identifies  responses  of  a  system  to  events 

Systems 

SV-lOc 

Systems  Event-Trace 

Description 

One  of  three  products  used  to  describe  system  functionality; 
identifies  system-specific  requirements  of  critical  sequences  of 
events  described  in  the  Operational  View 

Systems 

SV-11 

Physical  Schema 

Physical  implementation  of  the  Logical  Data  Model  entities, 
e.g.,  message  formats,  file  structures,  physical  schema 

Technical 

TV-1 

Technical  Standards  Profile 

Listing  of  standards  that  apply  to  Systems  Views  elements 
in  a  given  architecture 

Technical 

TV- 2 

Technical  Standards 

Forecast 

Description  of  emerging  standards  and  potential  impact  on 
current  Systems  Views  elements,  within  a  set  of  time  frames 
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Figure  3.9:  Process  for  Building  Architectures  [26] 
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3.6.2. 1  Step  One.  This  first  step  generated  many  important  questions. 


•  What  does  the  user  really  mean  by  integrated? 

•  Should  the  ISHMS  be  a  plug-and-play  device  or  should  it  be  networked  with 
various  internal  aircraft  components? 

•  Should  the  ISHMS  have  its  own  power  source  or  should  it  be  connected  to  the 
aircraft’s  power  source? 

•  Which  aircraft  structures  should  be  monitored? 

•  What  types  of  sensors  should  be  used  for  monitoring? 

•  How  many  sensors  are  required  to  satisfy  user  requirements? 

•  What  should  be  the  sampling  rate  of  the  sensors  in  order  to  satisfy  the  real-time 
monitoring  system  requirement? 

•  How  reliable  should  the  ISHMS  be? 

•  What  will  be  the  net  result  of  having  an  ISHMS  in  terms  of  saving  money? 

•  Should  the  current  time  between  inspections  be  increased?  If  so,  by  how  much? 

•  Should  the  number  of  inspection  items  be  decreased?  If  so,  by  how  many? 

•  Should  the  data  be  stored  and  downloaded  after  each  flight  or  will  it  be  moni¬ 
tored  in  near-real-time? 

•  Which  organizations  should  be  responsible  for  maintaining  and  sustaining  the 
system? 
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These  and  many  other  questions  form  the  basis  for  the  architectures,  ft  is 
important  to  always  keep  in  mind  the  user’s  perspective.  Obviously,  the  user  has  two 
primary  objectives: 

1.  To  save  money  by  not  having  to  replace  their  aging  aircraft  and  reducing  main¬ 
tenance  costs. 

2.  To  minimize  the  impact  to  their  operational  mission  by  reducing  the  current 
inspection  burden. 

The  system  architectures  were  built  with  these  two  objectives  in  mind. 

3. 6. 2. 2  Step  Two.  Once  the  purpose  and  content  of  the  architecture 
had  been  established,  the  second  step  in  the  architecture  building  process  was  to 
determine  the  architecture  descriptions  scope,  context,  environment,  and  any  other 
assumptions  considered.  In  terms  of  scope,  the  reader  is  referred  to  a  previous  section 
which  is  entirely  devoted  to  defining  and  scoping  the  problem.  However,  when  scoping 
the  architectures  the  team  was  primarily  interested  in  defining  the  ISHMS  mission(s), 
defining  those  activities  that  the  user  would  classify  as  being  necessary  functions  of  an 
ISHMS,  and  assigning  responsibility  to  the  potential  organizations  that  would  have 
to  interact  with  the  ISHMS. 

The  mission  of  the  ISHMS  is  to  provide  a  near-real-time  structural  monitoring 
of  an  aging  aircraft’s  FCLs  while  maintaining  or  improving  the  current  SOF  at  an 
affordable  cost.  The  primary  functions  that  the  ISHMS  must  provide  are  included  in 
the  architecture  and  will  be  explained  in  more  detail  in  Chapter  4.  The  team  had  some 
notional  ideas  as  to  which  organizations  will  most  likely  be  tasked  to  interact  with  the 
ISHMS;  however,  because  of  our  limited  knowledge  on  the  organizational  structure  of 
the  CAF,  the  architectures  only  show  hypothetical  entities.  Nevertheless,  the  task  of 
matching  these  hypothetical  organizations  to  the  real  organizations  should  be  fairly 
straight-forward. 
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For  the  most  part,  the  level  of  detail  in  the  architectures  was  left  intentionally 
rather  broad  since  the  team  was  only  dealing  with  the  initial  decomposition  and 
definition  leg  of  the  Vee-model.  Moreover,  the  limited  user  involvement  made  it 
impossible  to  go  deeper  into  defining  the  physical  configuration  items  of  the  ISHMS. 
Future  SE  thesis  groups  that  have  the  opportunity  to  interview  or  somehow  collect 
user  requirements  from  the  CAF  will  be  able  to  narrow  down  the  system  design 
requirements  and  perhaps  propose  a  physical  solution. 

3. 6. 2. 3  Step  Three.  Step  three  in  the  architecture  building  process  is 
to  determine  what  information  the  architecture  description  needs  to  capture.  Basically, 
this  step  is  about  making  sure  that  the  information  displayed  in  the  architectures  is 
relevant  and  correlates  with  the  information  collected  from  the  previous  steps.  DoDAF 
explains  that  “if  pertinent  information  is  omitted,  the  architecture  description  may 
not  be  useful;  if  unnecessary  information  is  included,  the  architecture  effort  may  prove 
infeasible  given  the  time  and  resources  available,  or  the  description  may  be  confusing 
and/or  cluttered  with  details  that  are  superfluous  to  the  issues  at  hand.”  [26] 

Several  MAPA  reports  on  the  ASIP,  SLEP  and  safe-life  programs  became  the 
backbone  of  the  thesis.  However,  policies  regarding  the  distribution  of  foreign  infor¬ 
mation  limited  and  almost  prevented  further  research  on  the  CAF  A-37  fleet.  After 
several  trials,  the  only  way  the  team  was  able  to  by-pass  this  obstacle  was  by  making 
an  assumption  that  the  A-37  and  the  USAF’s  T-37  aircraft  shared  similar  structural 
characteristics.  Even  though  initially  the  team  thought  that  this  assumption  was  a 
big  leap  from  reality,  the  list  of  the  top  ten  FCLs  for  both  aircraft  is  nearly  identical, 
thus  in  a  way  verifying  that  this  assumption  is  valid.  The  benefit  of  this  assumption 
should  be  obvious.  There  is  more  organic  information  available  on  the  T-37  because  it 
is  still  in  the  USAF’s  inventory.  Nevertheless,  the  team  realized  that  the  architectures 
were  limited  to  a  great  extent  by  the  information  that  was  available  and  accessible. 

3. 6. 2. 4  Step  Four.  The  next  step  is  to  determine  the  products  to 
be  built.  As  previously  stated,  the  DoDAF  has  a  significant  number  of  architecture 
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products  to  choose  from  depending  on  the  needs  and  preferences  of  the  architect. 
However,  the  DoDAF  states  that  “an  integrated  architecture  consists  of  AV-1,  AV- 
2,  OV-2,  OV-3,  OV-5,  SV-1,  and  TV-1  as  a  minimum  [27]”.  In  addition,  DoDAF 
provides  a  list  of  various  combinations  of  applicable  architecture  products  depending 
on  the  intended  use  of  the  architecture,  which  are  shown  in  Figure  3.10. 
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Figure  3.10:  Architecture  Products  by  Use  [27] 

From  the  list  of  recommended  architecture  uses  above,  only  two  choices  seemed 
to  fit  to  the  project  requirements:  (1)  System  Design  and  Development  or  (2)  an 
Acquisition  Strategy.  After  some  thought,  the  team  decided  that  it  was  not  feasible 
for  the  team  to  be  involved  in  the  physical  design  of  an  ISHMS.  Instead,  the  goal  was 
to  define  and  identify  possible  system  requirements  and  hopefully  demonstrate  the 
financial  feasibility  of  incorporating  an  ISHMS  into  an  aging  aircraft.  Thus,  the  team 
concluded  that  the  architecture  products  should  resemble  those  of  an  acquisition  strat¬ 
egy.  DoDAF  suggests  the  following  architecture  products  for  an  acquisition  strategy: 
AV-1,  AV-2,  OV-1,  OV-2,  OV-5,  SV-1,  SV-5,  and  TV-1.  Even  though  there  are  slight 
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differences  between  what  policies  require  and  what  DoDAF  recommends,  the  team 
decided  to  concentrate  the  efforts  on  creating  the  required  architecture  products  first. 
Any  other  architectures  that  the  team  considered  would  add  value  and  clarity  to  the 
analysis  would  be  generated  later.  All  the  architecture  products  will  be  presented  in 
Chapter  4.  An  aspect  of  system  architectures  development  that  may  seem  confusing 
is  the  fact  that  the  sequence  of  the  products  does  not  follow  their  logical  numerical 
sequence.  Even  though  the  actual  sequence  followed  is  a  matter  of  preference  and 
convenience,  Figure  3.11  depicts  the  suggested  developmental  sequence  taught  in  the 
Air  Force  Institute  of  Technology  Systems  Engineering  640  course.  The  team  adhered 
to  this  sequence  for  the  architecture  development. 


Figure  3.11:  Architecture  Products  Sequence  [48] 

3. 6. 2. 5  Steps  Five  and  Six.  The  last  two  steps  of  the  six-step  architec¬ 
ture  building  process  are  gather  the  architecture  data  and  build  the  requisite  products 
and  use  the  architecture  description  for  its  intended  purpose.  Both  of  these  steps  have 
been  briefly  discussed  in  this  section,  and  will  be  elaborated  in  Chapter  4. 
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Finally,  the  team  had  to  choose  the  format  or  language  in  which  the  team 
were  going  to  build  the  architectures.  The  DoDAF  offers  two  alternatives:  (1)  the 
Structured  Approach  and  (2)  UML.  The  team  based  the  decision  in  convenience, 
practicality,  and  personal  preference  of  the  architects.  In  all  three  categories  the 
Structured  Approach  came  ahead  of  the  UML.  This  was  widely  expected  since  UML 
is  mainly  used  for  software  development  although  its  use  has  increased  in  popularity 
in  the  recent  years. 

The  structural  model  scope  is  presented  in  the  next  section.  The  assumptions 
made,  the  purpose  of  this  model,  and  the  design  goals  are  analyzed.  Finally  the 
methodology  used  for  the  formulation  of  the  problem  is  presented  in  detail. 

3.7  Structural  Model  Scope  of  Work 

Fatigue  was  a  common  failure  mode  of  current  aircraft  structures.  This  was  be¬ 
cause  the  deterministic  calculations  of  traditional  fracture  mechanics  did  not  capture 
the  probabilistic  nature  of  material  properties,  manufacture  and  assembly,  mission 
profiles  flown,  etc.  This  created  a  possibility  of  calculating  a  nonconservative  fatigue 
crack  growth  at  a  FCL  (Figure  3.12). 

One  way  to  mitigate  the  possibility  of  a  nonconservative  crack  growth  prediction 
was  to  conduct  time  consuming  and  expensive  periodic  inspections.  The  comparison  of 
the  baseline  Cessna  A-37  300  hour  inspection  schedule  versus  the  extended  inspection 
schedule  with  an  ISHMS  installed  required  the  development  of  a  structural  model  to 
predict  the  stress  occurring  at  a  FCL.  The  FCL  chosen  was  the  wing  attach  fitting 
at  the  wing  root.  The  geometry  of  the  fatigue  crack  growth  was  that  of  crack  at  an 
edge  of  a  hole  in  tension  from  combined  loading  (Figure  3.13). 
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Figure  3.12:  Effects  of  Deterministic  Fatigue  Crack  Growth  Prediction  [49] 


Figure  3.13:  Wing  Attach  Fitting  Crack  Growth  Geometry  [28] 
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Additionally,  the  FCL  was  assumed  to  be  in  a  state  of  plane  stress(membrane). 
This  required  the  additional  assumptions: 

1.  Applied  loads  acted  in  the  midplane  direction  and  were  symmetric  with  respect 
to  the  midplane 

2.  Support  conditions  were  symmetric  about  midplane 

3.  In-plane  stresses,  strains,  and  displacements  were  uniform  through  the  thickness 

4.  Normal  and  shear  stress  components  in  the  z  direction  were  negligible 

5.  Plate  was  symmetric  with  respect  to  the  midplane 

6.  Material  was  homogeneous  [31] 

An  established  aircraft  usage  profile  (flight  spectrum)  was  used  along  with  a  typical 
Vietnam  era  weapons  loadout  of  2501  lb  to  estimate  crack  growth  and  determine  air¬ 
craft  service  life  (how  many  cycles  the  wings  can  be  loaded  until  fracture).  Countries 
can  save  maintenance  resources  by  maximizing  the  inspection  interval  of  the  aircraft 
currently  in  their  inventory  while  maintaining  safety  at  the  same  level  as  the  300 
hour  inspection  interval.  Flight  profiles  and  the  amount  of  weapons  carried  cannot 
be  modified  without  negatively  affecting  the  mission,  so  the  stress  model  at  the  FCL 
was  determined  with  the  pylon  weapon  loads  as  the  design  variables.  Each  weapon 
pylon  location  has  maximum  load  ratings,  but  this  structural  model  determines  the 
stress  applied  at  a  FCL  from  the  applied  weapons  load  and  flight  profile. 

This  analysis  modeled  (via  I-DEAS®  Finite  Element  Analysis),  metamodeled 
(via  JUMP®  response  surface),  and  established  a  simple  flight  spectrum  (via  Excel® 
stepped  approximation)  the  stress  in  the  subsonic  Cessna  A-37  Dragonfly  wing  struc¬ 
ture. 


3. 7. 1  Introduction.  The  purpose  of  this  structural  modeling  was  to  estimate 
crack  growth  propagation  at  a  FCL  to  facilitate  an  ISHMS  benefit  analysis. 


77 


Due  to  the  high  cost  of  procuring  new  aircraft,  many  countries  have  extended 
their  current  aircraft  inventory  service  lives  beyond  the  original  service  life.  Service 
life  was  determined  by  the  calculation  of  cycles  until  failure,  Nf  (Equation  3.1). 


Nf  = 


raf  i 

L  cJKk) 


(3.1) 


The  cycles  until  failure,  Nf,  was  calculated  based  upon  the  crack  growth  rate, 
da/dN  (Equation  3.2). 
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The  Walker  crack  growth  equation  was  used  (Equation  3.3). 


(3.2) 


da_  f  AK  \ 

dN  V(1 


(3.3) 


The  crack  growth  rate,  da/dN,  was  highly  sensitive  to  the  stress  intensity  range, 
AK,  (Equation  3.4)  and  material  constants,  C  &  m. 

The  material  constants  were  determined  from  the  NASGRO  database  (Figure 

3.14). 


AK  =  Kmax  -  Kmm  =  f(g )  •  A  a  \/  na  (3.4) 

The  stress  intensity  range,  AK,  was  based  on  the  stress  amplitude,  A  a,  the 
boundary  condition  factor,  f(g),  and  the  crack  length,  a.  The  stress  amplitude,  A  a, 
was  the  difference  between  the  maximum  and  minimum  stress  (Figure  3.15). 

Minimum  stress,  amin,  was  assumed  as  the  unloaded  wing  configuration  i.e., 
&min  =  0.  The  aircraft  flight  load  was  assumed  as  Straight  and  Level  Unaccelerated 
Flight  (SLUF).  The  goal  was  to  predict  the  maximum  stress,  amax,  from  the  SLUF 
and  weapon  loading  configurations.  The  difference  in  the  two  stresses  was  the  stress 
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Figure  3.14:  NASGRO  A1  7075-T6  [30] 
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Figure  3.15:  Stress  Amplitude  [28] 

amplitude  used  to  calculate  the  crack  growth  rate  and  cycles  until  failure,  Nf.  The 
maximum  stress,  <Jmax,  on  the  wing  was  determined  by  the  weight/location  of  the 
weapons  and  the  lift  load. 

The  weapons  point  load  stress  was  a  function  of  gravitational  force  of  the 
weapons  and  distance  from  the  wing  root  (Equation  3.5).  The  lift  distributed  load 
magnitude  was  equivalent  to  the  aircraft  weight  (SLUF  assumption)  and  distributed 
in  an  elliptical  manner  from  wing  tip  to  root  and  clliptically  from  leading  edge  to 
trailing  edge. 


a  = 
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F  •  x 
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■y 


(3.5) 


There  was  considerable  research  done  in  the  areas  low  cycle  fatigue,  design  of 
experiments,  (and  to  a  lesser  extent)  simulation  with  finite  elements,  and  regression  re¬ 
sponse  surface  metamodeling.  Literature  covering  these  modeling  topics  was  listed  in 
this  section.  Dowling  exhaustively  examined  the  factors  influencing  low  cycle  fatigue 
under  constant  amplitude  stress  [28].  Experimental  design  to  minimize  the  number 
of  simulations  was  well  known,  and  Central  Composite  Designs  were  available  from 
Draper  [64]  and  demonstrated  by  Penmetsa  [55] .  Shih  methodically  presented  the  use 
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of  the  I-DEAS®  finite  element  program  to  create  structural  simulation  models  [63]. 
Madu  and  Barton  offered  methodology  useful  to  fit  regression  response  surface  meta¬ 
models  to  simulations  [46].  Finally,  Miedlar  described  the  procedure  to  estimate  an 
aircraft  stress  sequence  [47]. 

3.8  Design  Goals 

The  design  variables  were  defined  as  the  amount  of  weapon  and  fuel  force  (lbf) 
loaded  at  each  of  the  four  pylon  locations  and  wing  tip  (xi,  x2,  x3,  X4,  &  x5)  (Figure 
3.16).  Note:  the  location  of  the  weapon  pylons  were  fixed  and  could  not  be  changed; 
only  the  amount  of  loading  at  each  pylon  location  was  changed. 


Figure  3.16:  Design  Variable  Definition  and  Location  [67] 


The  cost  function  was  the  aircraft  stress  (psi)  at  the  wing  root  spar  connection 
to  the  front  spar  carry-through  frame  (wing  attach  fitting)  element  2815  (Figure  3.17). 

3.9  Problem  Formulation 

Once  a  typical  A-37  weapon  load  was  determined,  the  development  of  the  cost 
function  was  broken  down  into  six  stages  and  four  parts.  The  first  stage  consisted  of 
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Figure  3.17:  Spar  Element  2815  Location 

researching  the  Cessna  A-37  Dragonfly  to  gain  an  understanding  of  the  structure  and 
forces  at  work.  The  second  stage  was  making  engineering  assumptions  to  simplify 
the  complex  A-37  system  into  a  structural  simulation  model.  The  third  stage  was 
distilling  the  simulation  model  down  into  a  response  surface  regression  metamodel  to 
estimate  the  stress  experienced  at  the  wing  attach  fitting.  The  forth  stage  created  a 
stepped  approximation  of  a  fighter  flight  spectrum  to  determine  mission  effects  on  the 
stress  at  the  wing  attach  fitting.  The  fifth  stage  was  feeding  the  stress  amplitude  per 
100  cycles  per  flight  hour  into  the  MATLAB®  crack  growth  model  to  estimate  crack 
growth  at  the  FCL  over  time.  The  sixth  stage  was  using  the  crack  growth  model  to 
conduct  a  benefit  analysis  (Figure  3.7). 
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3. 9. 1  Four  Parts  of  Structural  Model.  The  four  parts  to  successfully  execute 
the  structural  model  were: 

1.  Constructed  a  structural  simulation  model  of  the  Cessna  A-37  Dragonfly 

•  Created  a  simulation  model  of  the  wing  using  Finite  Element  (FE)  analysis 

•  Used  adaptive  meshing  to  decrease  element  size  until  max  stress  converged 

2.  Constructed  a  Central  Composite  Design  (CCD)  for  the  response  surface 

•  Generated  orthogonal  fractional  factorial  design  to  minimize  confounding 

•  Determined  design  factor  input  ranges 

3.  Executed  each  of  the  I-DEAS®  finite  element  simulation  runs 

•  Executed  required  simulations  from  the  fractional  factorial  design 

•  Validated  the  simulation  model  results  using  hand  calculations 

4.  Created  a  response  surface  regression  metamodel  of  the  FE  simulation  model 

•  Conducted  sensitivity  analysis  to  determine  loading  trends  on  stress 

•  Estimated  stress  at  wing  attach  fitting  using  typical  Vietnam  weapon  load- 
out 

5.  Constructed  stepped  approximation  of  fighter  flight  spectrum 

•  Simplified  flight  spectrum  for  crack  growth  model 

•  Estimated  mission  effect  on  wing  attach  fitting  stress  per  flight  hour  cycle 

In  the  final  section  of  this  chapter  the  ISHMS  benefit  analysis  is  discussed. 
The  assumptions  the  thesis  group  made  are  presented.  Also,  the  methodology  used 
to  conduct  the  benefit  analysis,  using  a  baseline  and  a  scenario  with  the  ISHMS 
installed,  is  explained. 
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3.10  ISHMS  Benefit  Analysis 


Utilizing  the  FCL  material  analysis  and  crack  growth  models  discussed  previ¬ 
ously,  this  thesis  performed  a  basic  analysis  to  help  verify  and  possibly  quantify  the 
potential  cost  and  safety  benefits  of  an  ISHMS  over  the  current  baseline  which  is 
to  continue  to  fly  aging  aircraft  with  the  increased  inspection  profile.  Monte  Carlo 
simulations  were  generated  using  MATLAB®  to  contrast  the  failure  rate  of  a  FCL 
and  number  of  inspections  performed  under  two  scenarios: 

1.  baseline  -  continue  to  fly  with  mandatory  300-hour  inspections 

2.  to  fly  with  the  same  300-hour  inspection  interval  but  the  additional  protection 
of  an  installed  ISHMS. 

The  only  difference  between  the  two  scenarios  was  the  ISHMS  monitors  the  FCL  in 
real-time  and  if  the  crack  grows  to  90%  of  critical  length,  the  ISHMS  provided  warning 
to  either  the  cockpit  or  the  ground  that  the  aircraft  must  land  and  be  inspected.  This 
design  assumption  helped  to  simplify  the  simulation  model.  Figure  3.18  provides  a 
graphical  depiction  of  the  perform  simulation  function. 

3.10.1  Simulation  Assumptions.  Some  simplifying  assumptions  were  made 
in  order  to  accurately  compare  the  two  scenarios.  The  simulations  assumed  only 
one  crack  growing  in  one  FCL.  The  effects  of  corrosion  were  not  included  in  the 
model.  Crack  propagation  was  the  only  contributing  factor  to  FCL  failure.  When 
cracks  are  discovered  through  maintenance  inspection,  they  are  repaired  and  the  new 
crack  length  is  assumed  to  be  the  longest  length  undetectable  to  the  human  eye. 
This  simulated  the  worst  case  of  maintenance  personnel  installing  a  new  part  with  a 
material  flaw,  but,  of  course,  that  flaw  is  not  seen  by  the  maintenance  personnel.  The 
maintenance  inspections  performed  for  both  scenarios  are  identical.  The  ISHMS  can 
monitor  the  entire  FCL  for  any  size  crack  initiated  in  any  location  on  the  FCL  and 
growing  in  any  direction.  Both  simulations  assumed  the  same  beginning  crack  length 
and  the  crack  growth  was  identical  for  each  simulation.  Each  simulation  simulated  a 
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Figure  3.18:  Perform  Simulation  Function 

fleet  of  13  A-37s  through  1000  trials  with  a  life  of  5000  flight  hours  for  each  aircraft. 
One  thousand  trials  were  chosen  to  maximize  the  number  of  trials  while  keeping  run 
times  reasonable.  The  team  selected  5000  additional  flight  hours  as  an  appropriate 
life  extension  timeframe  for  an  A-37  aircraft. 


3.10.2  Baseline  Scenario.  In  the  baseline  scenario,  the  FCL  began  with  one 
crack  set  to  the  initial  length  predetermined  from  the  material  analysis  performed 
on  the  FCL.  The  crack  grew  according  to  the  growth  model  and  at  intervals  of  300 
flight  hours  the  aircraft  was  inspected.  A  probability  of  the  maintenance  inspection 
detecting  the  crack  was  applied  to  the  simulation.  The  thesis  team  estimated  that 
maintenance  inspection  would  detect  97%  of  cracks.  This  probability  was  based  on  the 
experience  of  the  maintenance  officer  group  members.  Additionally,  any  error  in  this 
estimate  would  be  mostly  negated  because  both  simulations  used  the  same  probability 
estimate.  If  the  crack  was  detected,  repair  was  accomplished  that  effectively  removed 
the  crack  and  the  crack  length  was  reset  to  the  longest  crack  length  undetectable  by 
human  sight.  A  critical  crack  length  was  defined  from  the  material  analysis  performed 
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in  the  previous  sections.  If  the  crack  length  ever  exceeded  the  critical  crack  length, 
due  to  lack  of  detection  during  inspection  or  growth  prior  to  inspection,  then  failure  of 
the  fatigue  critical  location  and,  subsequently,  aircraft  failure  was  considered  a  result. 
As  stated  1000  trials  of  the  simulation  were  run  simulating  a  fleet  of  13  aircraft  for 
each  trial.  The  resulting  failure  rate  per  million  flight  hours  and  total  number  of 
inspections  were  calculated. 

3.10.3  ISHMS  Installed  Scenario.  As  in  the  baseline  scenario,  the  fatigue 
critical  location  began  with  one  crack  at  the  initial  length  and  crack  growth  was 
modeled.  A  design  assumption  for  the  ISHMS  had  to  be  made.  It  was  assumed  that 
the  ISHMS  provides  near-real-time  feedback  to  the  either  the  aircraft  pilot  or  ground 
control  on  the  status  of  the  monitored  structures.  The  ISHMS  signaled  when  the  crack 
length  had  reached  90%  of  critical  length.  For  the  simulation,  the  aircraft  will  undergo 
inspection  either  at  a  given  flight  hour  interval  or  whenever  the  ISHMS  indicates  90% 
critical  length.  If  the  ISHMS  indicated  a  crack  had  grown  to  90%  of  critical  length 
causing  an  unscheduled  inspection,  then  the  inspection  interval  clock  was  reset  and 
the  next  inspection  occurred  after  the  requisite  flight  hours.  There  was  a  probability 
of  detection  associated  with  the  ISHMS  detecting  the  crack  (99.9%)  and  a  separate 
probability  of  detection  with  the  inspection  detecting  the  crack,  if  not  tipped  off  by 
the  ISHMS  (same  as  baseline  -  97%).  These  probabilities  were  considered  by  the 
model.  However,  if  the  ISHMS  indicates  a  crack  near  critical  length,  the  probability 
of  detection  by  maintenance  inspection  was  100%.  As  in  the  baseline  scenario,  if  the 
crack  length  exceeded  the  critical  crack  length,  due  to  lack  of  detection  by  ISHMS 
and/or  inspection,  then  aircraft  failure  resulted.  Again  1000  trials  were  run  simulating 
a  fleet  of  13  aircraft  for  each  trial.  The  resulting  failure  rate  per  million  flight  hours 
tested  and  total  number  of  inspections  were  calculated. 

3.10.4  Sensitivity  Analysis.  The  probability  of  detection  for  both  the  main¬ 
tenance  inspection  and  the  ISHMS  were  selected  rather  arbitrarily.  To  examine  what, 
if  any,  changes  in  the  results  might  occur  if  the  probabilities  of  detection  were  differ- 


ent,  a  sensitivity  analysis  was  performed  on  the  maintenance  probability  of  inspection. 
If  the  probability  of  detection  for  maintenance  were  decreased,  the  safety  benefit  of  an 
ISHMS  would  certainly  increase;  therefore,  the  sensitivity  analysis  only  examined  the 
effect  of  increasing  the  maintenance  probability  of  inspection.  The  sensitivity  analysis 
did  not  vary  the  ISHMS  probability  of  detection,  because  the  thesis  team  believed 
that  99.9%  probability  of  detection  would  most  likely  be  the  minimum  acceptable 
probability  of  an  ISHMS  by  a  user. 


87 


IV.  Results 


Figure  4.1:  Chapter  4  Decomposition 


The  results  of  implementing  the  methodology  detailed  in  Chapter  3  are  pre¬ 
sented  here.  The  systems  engineering  products  which  help  to  define  the  system  are 
shown.  The  aircraft  wing  attach  fitting  material  analysis  and  modeling  is  detailed. 
The  chapter  concludes  with  the  output  of  the  benefit  analysis  comparative  simulation 
runs  to  quantify  the  potential  cost  avoidance  provided  by  installing  an  ISHMS  on 
aging  aircraft.  (Figure  4.1) 


4  •  1  Scope 

The  ISHMS  thesis  team  considered  many  different  aspects  of  the  problem  to 
adequately  scope  this  thesis.  Scoping  the  thesis  resulted  in  two  basic  deliverables. 
The  first  product  was  the  ISHMS  SE  design  process.  The  second  product  was  the 
benefit  analysis  of  installing  an  ISHMS. 

4-1.1  ISHMS  SE  Design  Process.  The  ISHMS  SE  design  process  involved 
a  significant  challenge  in  defining  the  problem  and  determining  the  problem  state¬ 
ment.  After  several  iterations,  the  problem  statement  converged  to  develop  a  systems 
engineering  approach  for  a  near  real  time,  cost- effective,  integrated  structural  health 
monitoring  system  for  an  aging  aircraft  while  maintaining  or  improving  the  safety  of 
flight  parameters.  The  original  scope  was  to  execute  the  SE  process  through  devel¬ 
opment  of  the  ISHMS  physical  architecture.  However,  limitations  of  time,  funding, 
sponsorship,  and  test  aircraft  availability  determined  the  scope  of  the  SE  design  pro¬ 
cess  to  the  functional  architecture.  Therefore,  this  thesis  focused  on  developing  a 
systems  engineering  approach  to  developing  the  functional  architecture. 

Each  aspect  of  the  problem  statement  was  defined. 

1.  Near  real  time 

2.  Cost-effective 

3.  Integrated  structural  health  monitoring  system 

4.  Safety  of  flight 

4. 1.1.1  Near  Real  Time.  Defining  near  real  time  was  broken  into  two 
parts.  The  first  part  was  determining  the  sampling  rate  of  the  sensors  at  the  FCLs. 
The  second  part  was  determining  the  communication  interval  of  the  ISHMS  system 
to  the  aircraft  operator  and  aircraft  maintenance  technicians. 

The  sampling  rate  of  the  sensors  of  the  ISHMS  was  estimated  by  dynamically 
modeling  the  first  bending  natural  frequency  mode  of  a  Cessna  A-37  wing  using 
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an  I-DEAS®  finite  element  structural  model.  This  modal  frequency  was  used  to 
determine  the  Nyquist  sampling  rate  of  the  sensors.  The  Inquest  sampling  rate  was 
the  minimum  sampling  rate  of  the  ISHMS  sensors  at  the  FCLs  to  capture  the  cyclic 
vibration  loading. 

The  communication  interval  of  the  ISHMS  system  was  determined  differently 
for  the  operators  and  maintainers.  The  aircraft  operator  was  notified  by  the  ISHMS 
when  crack  length  sensors  estimated  only  10%  of  the  fatigue  life  was  remaining.  This 
impending  failure  pilot  notification  allowed  a  reasonable  amount  of  time  to  land  the 
aircraft  for  inspection  and  repair.  The  communication  interval  for  the  maintenance 
personnel  was  based  upon  the  extended  maintenance  interval  for  the  installed  ISHMS 
(approximately  every  600  flight  hours). 

4- 1-1-2  Cost-effective.  Defining  cost-effective  for  this  thesis  was  very 
difficult.  The  total  life-cycle  cost  of  the  ISHMS  must  be  less  than  the  cost  of  continuing 
the  current  course  of  action  of  inspecting  at  a  predetermined  amount  of  flight  hours 
flown  (i.e.  300-hour  inspection  interval).  The  ISHMS  life-cycle  costs  include  every 
cost  from  cradle-to-grave: 

1.  Cost  of  design 

2.  Cost  of  acquisition 

3.  Cost  to  install  the  ISHMS 

4.  Additional  Cost  of  disposal 

5.  Cost  of  transmitting  the  data  (if  commercial  satellites  used) 

6.  Training  to  use  equipment 

7.  Cost  to  maintain  the  ISHMS 

Unfortunately,  costs  for  the  baseline  300  hour  structural  inspections,  as  well  as,  the 
additional  cost  of  installing  the  ISHMS  sensors  and  components  were  not  available. 
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Cost-effective  was  defined  by  the  cost  avoidance  of  utilizing  the  ISHMS  versus 
the  baseline  300  hour  inspection  scenario.  The  ISHMS  was  determined  cost-effective 
if  there  was  an  estimated  cost  avoidance  from  utilizing  the  ISHMS  versus  the  current 
300  hour  inspection  intervals. 

4. 1.1.3  Integrated.  Defining  integrated  for  the  ISHMS  was  much  easier 
than  determining  the  level  of  integration  required.  Ideally,  the  ISHMS  was  integrated 
among  the  FCL  sensors  and  throughout  the  aircraft  subsystems.  However,  the  expense 
of  a  new  ISHMS  subsystem  integration  into  existing  legacy  aircraft  subsystems  (e.g. 
power,  avionics,  etc.)  was  considered  cost  prohibitive.  The  ISHMS  different  types 
of  sensors  (i.e.  strain  gauges,  peizo-electric,  etc.)  were  integrated  to  monitor  fatigue 
and  crack  growth.  The  ISHMS  was  assumed  to  detect  all  types  of  fatigue/ cracks 
growing  in  any  direction  at  all  lengths  for  all  of  the  critical  locations  that  were  being 
monitored.  All  the  FCL  sensors  must  be  integrated  to  provide  a  high  level  of  accuracy 
and  reliability. 

The  advantages  of  installing  an  ISHMS  were  weighed  against  the  increased  costs. 
The  ISHMS  thesis  group  decided  to  minimize  ISHMS  integration  with  the  existing 
legacy  aircraft  subsystems  to  avoid  increased  design,  installation,  and  testing  costs. 
The  ISHMS  was  defined  as  integrated  if  the  ISHMS  had  the  ability  to  collect  and 
synthesize  the  various  FCL  sensor  data  and  provide  structural  health  cuing  to  the 
pilot  while  storing  the  data  for  maintenance  retrieval. 

4. 1.1-4  Safety  of  Flight.  Safety  of  Flight  was  defined  as  the  USAF 
standard  of  10  ‘  probability  of  fracture  per  flight  hour  [65].  The  acceptable  level  of 
risk  was  one  loss  per  1000  aircraft  over  the  life  of  the  weapon  system. 

4-1.2  Benefit  Analysis.  Previous  attempts  to  quantify  the  benefit  of  in¬ 
stalling  an  ISHMS  on  legacy  aircraft  were  not  found  during  the  team’s  review  of 
relevant  literature  on  the  subject.  The  primary  purpose  of  installing  an  ISHMS  was 
reducing  the  operating  cost  of  flying  legacy  aircraft.  The  ISHMS  team  decided  that 
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estimating  the  cost  avoidance  and  safety  benefit  of  installing  an  ISHMS  was  an  im¬ 
portant  deliverable  adding  to  the  current  body  of  knowledge.  The  ISHMS  team  used 
the  Cessna  A-37  as  the  benefit  analysis  example  aircraft.  A  finite  element  wing  struc¬ 
tural  model  was  constructed  and  a  static  stress  analysis  was  conducted  to  determine 
an  FCL  location  at  the  front  spar  wing  attach  point.  This  FCL  was  chosen  for  the 
analysis  because  of  the  high  stress  at  the  front  wing  spar  attach  point.  The  FCL 
location  was  verified  with  current  A-37  maintenance  data  as  a  fatigue  crack  growth 
location.  The  wing  attach  fitting  geometry  and  structural  simulation  model  were  used 
to  predict  stress  at  the  FCL  location  for  level  flight.  A-37  mission  profile  data  was  not 
available,  so  a  general  fighter  aircraft  stress  sequence  was  used  to  determine  the  stress 
effect  per  flight  hour  cycle.  The  results  were  inserted  in  the  Walker  crack  growth 
equation.  Two  MATLAB®  crack  growth  and  detection  simulations  were  performed 
to  gain  a  rudimentary  analysis  of  the  benefit  of  an  installed  ISHMS  with  respect  to 
both  safety  and  cost.  Maintenance  interval  was  incrementally  increased  on  the  ISHMS 
to  determine  cost  avoidance  possible  on  an  ISHMS  aircraft  at  an  equivalent  level  of 
safety  to  the  baseline  300  hour  inspection  aircraft. 

The  SE  process  and  benefit  analysis  were  discussed  in  following  sections  of  the 
thesis.  By  focusing  the  scope  to  a  Cessna  A-37  example,  the  amount  of  assumptions 
made  actually  increased.  The  ISHMS  team  realized  that  the  definition  of  the  physical 
architecture  by  follow-on  thesis  groups  will  improve  the  fidelity  of  utilizing  an  SE 
process  for  the  design  of  an  ISHMS. 

The  results  of  the  SE  process  life-cycle  phases  are  presented  in  the  following 
section.  Analogous  to  the  life  cycle  phases  of  an  aircraft,  the  SE  process  is  grouped 
into  periods  that  allow  the  methodical  discovery  and  refinement  of  the  ISHMS  re¬ 
quirements. 

f.2  Life-cycle  Phases 

The  term  life-cycle  is  used  to  represent  a  series  of  stages  through  which  a  system 
passes  from  its  inception  to  its  retirement.  Life-cycle  is  also  characterized  as  “birth 
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to  death”  [17].  The  life  of  any  system  begins  with  the  emergence  of  a  need  for  the 
users.  The  next  step  is  the  definition  of  this  need  and  of  the  system  requirements,  so 
that  the  stakeholders’  expectations  from  the  system  are  reflected  in  the  design.  This 
step  is  the  beginning  of  the  development  period  where  the  systems  engineers  and  the 
stakeholders  are  working  together.  Following  the  completion  of  the  design  phase  is 
the  integration  phase,  the  production,  the  operational  use,  the  refinement  and  finally 
the  retirement,  disposal  or  replacement  phase  [17].  During  the  design  phase  all  these 
phases  must  be  taken  into  consideration  otherwise  the  design  may  end  up  being  a 
failure. 

These  phases  can  be  grouped  into  four  periods.  First  is  the  development  period, 
where  the  requirements,  architecture  and  models  are  developed.  Production,  training 
and  deployment  take  place  during  the  second  period.  During  the  third  period  the 
operational  use  of  the  system  takes  place  along  with  the  maintenance  and  (if  needed) 
the  refinements/improvements.  Retirement,  disposal  and  replacement  take  place  at 
the  end  of  the  life-cycle  and  consist  the  fourth  period. 


Figure  4.2  shows  one  way  to  depict  the  life-cycle  phases  and  the  periods  de¬ 
scribed  above. 


Figure  4.2:  Lifc-cycle  Phases 
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The  thesis  team  can  see  that  there  is  a  fifth  period,  which  is  shown  on  the  left 
side  of  the  figure.  This  period  is  not  clearly  part  of  the  life-cycle  of  the  system  since 
the  design  has  not  started  and  the  system  does  not  exist  yet.  However,  it  is  during 
this  time  that  the  need  for  the  system  emerges  (usually  imposed  by  a  problem  that 
needs  to  be  solved  or  a  situation  that  must  be  improved)  and  the  system  concept 
(a  high  level  definition  of  the  system’s  function)  starts  taking  shape.  Therefore,  this 
period  is  depicted  in  the  figure. 

Although  the  life-cycle  phases  are  shown  as  distinct  and  separate  items  in  the 
figure,  in  fact  they  are  not.  Each  phase  is  a  continuation  of  the  previous  one.  Also, 
this  categorization  of  the  life-cycle  phases  and  their  grouping  into  four  periods  is  not 
a  unique  approach  and  it  is  not  generally  applicable  to  every  system.  Differences  in 
the  categorization  of  the  life-cycle  phases  are  very  common  among  different  products, 
customers  and  industries  [20].  However,  for  the  purpose  of  this  thesis,  this  is  the 
categorization  of  the  life-cycle  phases  that  will  be  used  for  the  ISHMS. 

4-3  ISHMS  Stakeholders 

The  thesis  team  mentioned  in  the  methodology  that  it  created  a  list  of  the 
ISHMS  life-cycle  phases  and  tried  to  identify  the  stakeholders  for  each  phase.  Then, 
by  playing  the  role  of  the  stakeholders,  the  thesis  team  tried  to  understand  and 
describe  the  viewpoint  and  the  requirements  of  each  category  of  stakeholders. 

In  order  to  identify  the  stakeholders,  a  critical  question  the  thesis  team  had  to 
answer  was  “who  has  the  right  to  have  a  requirement  for  the  system?”  [17] 

For  the  first  phase,  identification  of  need,  the  thesis  team  identified  the  Coali¬ 
tion  Force’s  Ministry  of  National  Defense,  and  the  Coalition  Air  Force  as  the  main 
stakeholders.  Both  these  stakeholders  are  part  of  the  country’s  government  who  is 
the  ultimate  stakeholder.  The  government,  however  is  a  more  conceptual  stakeholder 
(who  needs  to  ensure  the  safety  of  the  country  and  organize  its  defense)  who  does 
not  pose  requirements  directly  related  to  the  system.  Both  these  stakeholders  can  be 
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further  broken  down  (based  on  their  organizational  structure  and  the  hierarchy)  into 
smaller  groups  of  people  who  have  a  need  for  the  ISHMS. 

The  stakeholders  on  the  Ministry  of  Defense  side  are  the  Joint  Operations  Plan¬ 
ning  agencies.  They  need  to  ensure  enough  air  strike  capabilities  are  available  in  order 
to  accomplish  the  defense  operational  plans.  Since  the  A-37  aircraft  are  undergoing 
long  inspections,  are  not  mission  available  and  are  also  close  to  the  end  of  their  design 
life,  these  stakeholders  have  the  problem  that  they  cannot  achieve  their  capabilities 
goals.  Usually,  the  Ministry  of  Defense  is  controlling  the  defense  budget  so  the  Fi¬ 
nance  and  Acquisition  agencies  can  be  considered  as  the  bill  payers  and  subsequently 
as  stakeholders. 

At  this  point,  the  thesis  team  should  note  that  for  the  analysis  in  this  thesis  a 
basic  assumption  was  the  two  main  stakeholders,  Ministry  of  Defense  and  the  CAF, 
have  already  conducted  an  analysis  for  the  problem  they  are  facing  and  have  identified 
the  ISHMS  as  the  most  beneficial  solution.  Therefore,  further  analysis  is  centered  on 
this  solution  only. 

The  CAF  has  a  number  of  airplanes  and  weapons  in  its  inventory  and  trained 
personnel  to  operate,  maintain,  and  support  those  airplanes  in  order  to  be  able  to 
satisfy  the  Ministry  of  Defense  requirements.  Also,  it  has  a  budget  that  limits  its 
ability  to  maintain  and/or  increase  this  force.  The  CAF  has  a  limited  level  of  support 
capabilities  (facilities,  equipment,  personnel)  that  put  restrictions  on  the  amount  of 
maintenance  it  can  be  performed.  As  the  thesis  team  discussed  the  problem  for 
the  CAF  arises  from  the  fact  that  some  of  their  A-37  aircraft  are  approaching  their 
design  life  limit  and  are  either  unavailable  due  to  extensive  maintenance  or  about  to 
be  retired  (thus  reducing  the  total  amount  of  operational  capabilities).  This  situation 
consumes  a  larger  than  the  normal  amount  of  the  CAF’s  financial  resources  and 
consumes  additional  support  capabilities  thus  creating  more  problems. 
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On  the  CAF’s  side,  the  thesis  team  can  distinguish  four  groups  of  people/a¬ 
gencies  that  are  affected  by  this  problem  and  are  in  need  of  a  solution:  Operations, 
Maintenance,  Logistics/ Acquisitions,  Flight  Safety. 

The  operations  agencies  can  be  broken  down  into: 

•  Headquarters  Operations  (HQ)  agencies  (whose  purpose  is  Mission  Planning) 

•  Base  Level  Operations  (who  are  involved  with  pilot  training  and  mission  execu¬ 
tion) 

•  Squadron  Level  Operations  (namely  the  pilots) 

The  HQ  Operations  agencies  are  responsible  for  maintaining  a  certain  level  of 
air-power  readiness  in  order  to  be  able  to  execute  the  defense  plans  assigned  to  the 
CAF  by  the  Ministry  of  Defense,  their  customers.  These  agencies  set  the  acceptable 
aircraft  availability  limits  the  Base  Level  Operations  must  maintain.  Base  Level 
Operations  must,  also,  maintain  a  certain  level  of  training  and  expertise  for  their 
pilots  and  be  able  to  execute  the  missions  assigned.  The  Squadron  Level  Operations 
needs  to  execute  the  training  program  and  maintain  their  readiness  at  the  level  their 
customers  (Base  Level  Operations)  require. 

The  situation  created  by  the  aging  of  the  A-37  aircraft  (reduced  availability, 
possible  restrictions  in  the  operational  use  of  the  aircraft,  reduced  number  of  air¬ 
craft  due  to  life  exhaustion,  etc)  prevents  all  these  agencies  from  accomplishing  their 
goals.  Therefore,  these  agencies  need  a  solution  that  will  permit  them  to  achieve  the 
availability  and  accomplish  the  training  requirements. 

From  the  viewpoint  of  this  category  of  stakeholders  (especially  the  pilots),  the 
health  monitoring  system  should  relieve  the  current  restrictions  in  the  operational  use 
of  the  aircraft  (e.g.,  configuration,  flight  envelope  restrictions)  and  they  do  not  want 
new  restrictions  imposed  because  of  the  system. 
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The  people  involved  with  aircraft  maintenance  that  can  impose  requirements 
on  the  system  can  be  categorized  as  follows: 

•  CAF  engineers 

•  Maintainers  at  the  CAF  HQ 

•  Maintainers  at  the  Base  Level 

•  Maintainers  at  the  Squadron  level 

The  CAF  engineers  must  deal  with  the  aging  A-37  problem.  They  need  to  decide 
whether  to  retire  the  aircraft  that  reach  their  design  life  or  extend  their  operational 
use.  If  they  decide  the  latter,  they  need  to  decide  how  this  will  be  accomplished 
and  how  long  this  extension  will  be.  From  their  viewpoint  an  ISHMS  that  records 
and  analyzes  aircraft  usage  data  will  allow  them  to  assess  the  aircraft  condition, 
predict  the  remaining  useful  life  and  make  decisions  on  the  aircraft  life  extension 
and  maintenance.  They  expect  that  this  system  will  permit  the  development  of  a 
customized  maintenance  schedule  which  will  have  as  a  result  the  increase  of  the  aircraft 
availability.  At  the  same  time,  they  expect  high  reliability  from  the  system  that  will 
be  a  valuable  tool  for  achieving  their  goals. 

The  maintainers  at  the  HQ  need  to  find  a  solution  to  the  problem  created  by 
the  A-37  aircraft.  There  is  increased  downtime  and  reduced  number  of  operational 
aircraft  due  to  the  extensive  inspections  and  repairs.  Also,  these  inspections  consume 
more  resources  (facilities,  equipment,  personnel)  than  expected,  and  hinder  the  main¬ 
tainers  at  the  Base  and  Squadron  Levels  from  satisfying  their  customers’  (Operations) 
requirements:  provide  mission  ready  aircraft  on  time.  The  maintainers  expect  a  sys¬ 
tem  that  will  be  able  to  track  the  actual  usage  of  the  A-37  and  monitor  the  structural 
damages.  They  expect  that,  if  they  have  this  information  they  will  be  able  to  inspect 
and  repair  only  the  problem  areas  on  the  aircraft  that  must  be  inspected/repaired. 
This  will  reduce  the  amount  of  teardown  and  the  maintenance  effort  overall.  Also, 
they  want  to  be  able  to  perform  inspections  when  it  is  required  and  not  according 
to  a  preset  schedule  which  may  not  reflect  the  true  condition  of  the  aircraft.  At  the 
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Base  and  Squadron  levels  this  will  allow  better  use  of  the  resources  (especially  the 
personnel). 

Another  assumption  that  the  thesis  team  made  was  that  the  CAF  does  not  have 
an  aircraft  depot  facility  and  any  depot  maintenance  required  is  accomplished  at  a 
commercial  aircraft  depot  either  in  the  same  or  in  another  country. 

Because  many  of  these  structural  inspections  are  being  conducted  at  a  depot 
facility  the  CAF  has  to  pay  for  this  maintenance.  The  maintainers  at  the  HQ  believe 
that  the  installation  of  a  health  monitoring  system  will  reduce  this  portion  of  the 
maintenance  costs. 

The  Logistics  agencies  are  coping  with  problems  in  the  support  of  these  aged 
aircraft.  Currently,  they  have  a  hard  time  getting  the  required  structural  parts  in 
a  timely  manner  when  a  repair  is  needed.  They  found  out  that  by  ordering  parts 
based  on  the  preset  maintenance  schedule  of  the  structural  inspections,  they  end  up 
paying  for  and  receiving  parts  that  are  not  truly  required  on  every  aircraft  (which 
means  wasted  resources).  The  reason  is  that  the  preset  schedule  assumes  that  some 
parts  will  be  defective  and  will  require  replacement.  However,  when  some  aircraft  are 
inspected  they  may  not  exhibit  the  expected  findings  and  there  may  not  be  a  need  for 
replacement  parts.  On  the  other  hand,  parts  required  for  a  specific  aircraft  based  on 
its  condition  may  not  be  immediately  available  because  there  was  no  prediction  for 
this  requirement,  and  that  increases  the  aircraft  downtime.  They  perceive  the  ISHMS 
as  a  system  that  will  allow  for  better  predictions  in  the  maintenance  requirements  and 
will  result  in  more  accurate  parts  order  and  less  waste. 

The  CAF  Acquisition  agencies  have  a  problem  because  the  A-37  aircraft  inspec¬ 
tions  consume  an  increased  portion  of  the  budget  due  to  higher  maintenance  costs. 
They  have  already  done  their  analysis  and  expect  the  acquisition  of  this  new  system 
will  help  better  control  the  A-37  fleet’s  direct  operating  costs.  They  have  their  esti¬ 
mates  for  the  ISHMS  costs  and  expect  a  physical  realization  of  the  system  to  meet 
these  estimates. 


Flight  Safety  agencies  are  probably  the  stakeholders  with  the  strictest  demands. 
They  are  in  charge  of  setting  the  acceptable  safety  limits  and  ensuring  the  limits 
are  being  followed.  They  have  a  hard  time  with  the  A-37  fleet:  the  increased  age 
is  translated  into  increased  risk.  They  want  to  be  sure  that  if  an  A-37  is  allowed 
to  continue  flying  (especially  beyond  its  original  design  life)  this  is  done  without  any 
compromise  or  any  violation  of  the  required  safety  level.  They  expect  from  an  ISHMS 
to  maintain  at  least  the  same  level  of  safety  as  the  current  solution  of  performing  the 
structural  inspections.  All  these  stakeholders,  for  the  first  phase  of  the  life-cycle,  are 
shown  in  Figure  4.3. 
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Figure  4.3:  Stakeholders  Identification  of  Need 


The  second  phase  of  concept  definition  cannot  be  separated  from  the  first.  There 
is  not  any  major  change  in  the  stakeholders  but  now  the  systems  engineers  (develop- 
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ers)  are  required  to  work  with  the  representatives  of  the  stakeholders  detailed  above 
and  transform  their  generic  needs  into  an  operational  concept.  They  also  need  to 
identify  the  subsequent  phases  and  the  stakeholders  involved  in  these  phases. 


In  the  following  phases  (preliminary  system  design,  configuration  item  design, 
system  integration),  which  consist  the  development  period,  the  main  stakeholders  are 
the  systems  engineers  (developers)  and  the  system  designers.  The  manufacturers  have 
also  a  role  while  the  regulatory  agencies  and  the  U.S.  Department  of  Defense  (DoD) 
may  impose  requirements.  The  stakeholders  for  the  development  phase  of  the  system 
are  depicted  in  Figure  4.4. 
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Figure  4.4:  Development  Phase  Stakeholders 


The  developers  at  this  phase  want  to  define  the  system  requirements  based  on 
the  concept  definition  they  created  previously.  They  also  want  to  define  the  architec¬ 
ture  of  the  system  and  make  sure  it  reflects  the  other  stakeholders’  views.  At  the  same 
time  they  must  pay  attention  in  treating  the  system  as  a  black  box  (which  is  quite 
difficult  to  do).  This  means  they  should  not  direct  the  designers  towards  a  specific 
realization  of  the  system  at  this  time  but  instead,  they  should  keep  their  focus  on 
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the  functions  of  the  system.  They  are  responsible  for  envisioning  the  evolution  of  the 
system  through  its  life-cycle.  The  schedule  constraints,  the  availability  of  funding, 
the  operational  requirements,  the  system’s  performance  and  the  technology  applied 
should  be  balanced  by  these  stakeholders. 

The  designers  are  another  group  of  stakeholders  since  they  are  involved  with  the 
transformation  of  the  requirements  and  architectures  into  a  physical  solution.  Their 
vision  of  the  system  may  be  different  than  the  vision  the  other  stakeholders  may  have. 
But  the  designers  must  keep  in  mind  that  it  is  the  customers’  needs  they  are  trying 
to  satisfy  with  the  design  and  not  their  personal  visions  or  goals.  In  this  sense  the 
technologies  they  are  going  to  use  for  the  design  should  not  be  selected  on  the  basis 
of  “technology  for  the  technology’s  sake”  [1]. 

The  manufacturers  start  getting  involved  during  these  phases.  They  expect 
that  the  system  design  they  will  have  to  materialize  will  be  feasible.  This  means  that 
the  technology  involved  and  the  resources  required  will  be  within  their  capabilities. 
Also,  their  financial  goals  (from  the  manufacturing  of  this  system)  will  create  some 
requirements  for  the  system  design.  Clear  definition  of  the  requirements  is  expected 
in  order  to  avoid  misunderstandings  later  on.  The  manufacturers  view  this  phase  as 
the  preparation  stage  for  their  more  extended  involvement  later  on. 

By  the  term  regulatory  environment  the  thesis  team  refer  to  all  those  agencies 
that  can  impose  requirements  and  rules  that  affect  the  design,  production  and  opera¬ 
tion  of  the  system.  These  agencies  usually  are  external  to  the  system’s  environment. 
Rules  regarding  the  use  of  hazardous  material  in  manufacturing  and  operation  and 
the  production  of  toxic  waste  for  example  should  be  taken  into  account  during  the 
design.  In  this  sense,  the  regulatory  environment  is  another  stakeholder  at  this  phase. 

During  the  design  phases  as  well  as  in  the  subsequent  phases  (i.e.  Production, 
Operation)  the  U.S.  DoD  is  another  significant  stakeholder.  The  reason  is  that  the 
CAF  has  coordinated  the  development  of  their  A-37  ISHMS  with  the  U.S.  DoD.  The 
DoD  has  the  right  to  limit  the  amount  and  the  types  of  technology  that  can  be 
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released  to  other  countries,  and  because  the  development  of  the  ISHMS  will  be  done 
by  researchers  in  the  United  States,  therefore  the  DoD  can  impose  some  requirements 
(restrictions)  for  the  capabilities  of  the  system. 

In  the  production,  phase  the  manufacturers  (contractors)  are  the  main  stake¬ 
holders.  Other  stakeholders  are  the  CAF  engineers  and  acquisition  officers,  and,  as 
the  thesis  team  mentioned,  the  US  DoD  and  the  regulatory  agencies. 

A  part  of  the  manufacturers’  view  of  the  system  at  this  phase  was  described 
earlier.  Their  main  expectation  is  that  the  undertaking  of  producing  the  system  will 
be  beneficial  for  them.  The  system’s  production  requirements  should  not  create  addi¬ 
tional  difficulties  in  their  activities.  Their  investment  for  this  production  in  additional 
equipment  needed  is  expected  to  pay  off.  Along  with  setting  up  the  production  line, 
the  manufacturers  must  consider  during  this  phase  the  support  they  will  provide  to 
their  customers  (i.e.  training,  technical  support).  They  should  not  forget,  though, 
the  regulatory  agencies  and  their  restrictions  when  organizing  the  production  line  in 
order  to  avoid  any  conflicts  that  might  affect  the  timely  production  of  the  system. 

A  problem  related  with  the  production  is  the  selection  of  suppliers.  Very  often 
this  decision  at  this  phase  will  affect  the  system’s  support  in  the  subsequent  phases  and 
the  manufacturer  should  take  into  consideration  factors  such  as  the  life  expectancy  of 
the  system,  the  technology  involved,  and  the  ability  of  the  various  suppliers  to  provide 
the  parts  needed  in  the  long  term. 

The  CAF  Acquisition  officers  need  to  ensure  at  this  phase  that  contractual 
obligations  are  being  met  by  the  manufacturer.  The  Air  Force  engineers  are  working 
with  the  manufacturer  and  are  monitoring  the  production  process  to  verify  that  the 
technical  specifications  are  followed.  Their  feedback  is  expected  by  the  acquisitions 
officers  in  order  to  verify  that  the  production  proceeds  according  to  the  schedule  and 
the  contract. 

As  the  production  of  the  first  systems  goes  to  its  completion,  the  final  prepara¬ 
tions  for  the  next  two  phases  begin.  Training  as  well  as  the  system’s  deployment  is 
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organized  at  this  time.  In  the  training  phase,  the  two  large  categories  of  stakeholders 
are  the  trainers  and  the  trainees.  In  the  trainers  category  the  manufacturer  and  the 
CAF  training  agencies  are  the  main  stakeholders.  The  category  of  trainees  consists 
of  the  system  operators,  the  system  maintainers,  and  the  aircraft  operators  (pilots). 
The  manufacturer’s  technical  personnel  involved  with  the  support  of  the  system  in 
subsequent  phases,  have  also  requirements  for  training. The  groups  of  stakeholders 
during  the  training  phase  are  depicted  in  Figure  4.5 


Figure  4.5:  Training  Phase  Stakeholders 


Usually,  the  manufacturers  of  systems  complex  and  expensive  such  as  the  ISHMS 
have  their  own  training  personnel  to  provide  training  to  their  customers.  These  train¬ 
ers  produce  the  training  material  and  organize  the  training  requirements.  Duration 
of  training,  location  of  training  (manufacturer’s  facilities  or  customer’s  site),  type  of 
training  (theoretical  in  class  training,  hand-on  training,  combination)  and  training 
aids  are  factors  that  must  be  considered  by  the  trainers. 
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The  CAF  internal  rules  impose  requirements  on  the  form  of  training.  The  CAF 
training  agencies  need  to  ensure  that  the  training  provided  by  the  manufacturers  is 
according  to  their  requirements.  Most  importantly  they  must  ensure  that  the  training 
goals  are  accomplished  and  the  trained  personnel  are  knowledgeable  enough  to  operate 
and  support  the  new  system. 

The  trainees  expect  from  the  training  to  provide  them  with  the  necessary  knowl¬ 
edge  to  support  the  system  once  it  becomes  operational.  Each  group  of  trainees  (op¬ 
erators,  maintainers,  pilots)  has  different  expectations  from  this  training.  That  is 
translated  into  a  requirement  the  development  of  training  programs  adapted  to  the 
needs  of  each  group. 

The  deployment  phase  cannot  be  clearly  separated  from  the  production  and 
training  phases.  Essentially,  the  completion  of  the  first  systems  and  the  beginning  of 
the  personnel  training  initiate  the  deployment  phase.  During  this  phase  the  groups  of 
people  that  have  the  right  to  have  requirements  for  the  system  are  the  manufacturers, 
the  groups  within  the  CAF  described  earlier  (i.e.  Headquarters,  Base,  Squadron, 
Operations,  Maintenance)  as  well  as  the  developers.  The  stakeholders  for  this  phase 
are  shown  in  Figure  4.6. 

At  this  phase,  the  manufacturers  have  completed  production  and,  in  coordina¬ 
tion  with  the  CAF  organize  the  installation  of  the  system  on  the  aircraft.  Details 
such  as  where  the  installation  will  take  place,  who  will  perform  it,  how  integration 
testing  will  be  done  need  to  be  clarified  before  the  deployment  begins.  The  manufac¬ 
turers’  expectation  is  that  the  system  could  be  installed  during  another  scheduled  or 
unscheduled  maintenance  in  order  to  reduce  the  installation  time.  They  would  like  to 
be  able  to  perform  testing  within  a  relatively  short  period  of  time  and  even  combine 
this  testing  with  other  operational  tests  performed  on  the  aircraft.  They  would  like  to 
minimize  the  potential  problems  that  could  arise  during  the  installation.  Their  basic 
goal  is  to  minimize  their  portion  of  the  costs  related  to  the  system’s  deployment. 
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Figure  4.6: 


Deployment  Phase  Stakeholders 
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On  the  CAF’s  side  decisions  concerning  the  location,  the  personnel,  and  the 
support  equipment  required,  should  have  been  made  at  the  beginning  of  this  phase. 
Their  participation  in  the  installation  of  the  system  as  well  as  the  requirements  for 
the  acceptance  of  the  new  system  must  be  clearly  defined  in  order  to  avoid  delays  and 
conflicts  with  the  manufacturers.  Their  main  expectation  is  that  the  integration  of 
the  system  on  the  aircraft  will  have  minimum  impact  on  the  operational  use  of  the 
aircraft. 

The  developers,  on  the  other  hand,  are  eager  at  this  phase  to  see  the  results  of 
their  work.  Their  main  expectation  is  that  the  design  they  produced  and  the  planning 
they  have  done  will  permit  the  deployment  of  the  system  to  be  completed  with  the 
minimum  impact  to  the  other  stakeholders  (manufacturers,  CAF  agencies). 

During  the  operation  phase  the  stakeholders  are  the  same  as  in  the  very  first 
phase  identification  of  need.  As  the  thesis  team  discussed  the  reason  for  the  design 
and  production  of  the  ISHMS  for  the  CAF  A-37  fleet  was  a  problem  that  affected 
the  stakeholders  such  as  the  country’s  Ministry  of  Defense,  the  CAF,  and  a  number 
of  agencies  in  these  two  organizations:  the  Operations  agencies,  the  Maintenance 
organizations,  the  Flight  Safety  agencies,  etc.  All  these  categories  of  stakeholders 
were  affected  by  the  main  problem  in  different  ways,  and  therefore  they  had  different 
expectations  and  visions  for  the  system.  The  expectations  and  the  vision  of  each 
stakeholder  from  the  operation  of  the  system  have  already  been  presented. 

As  the  system  becomes  operational  each  category  of  stakeholders  is  evaluating 
to  what  degree  this  system  satisfies  their  needs.  This  is  essentially  the  phase  where 
the  stakeholders  decide  whether  all  the  effort,  the  expenses,  and  the  wait  were  worth 
it. 

Hopefully,  the  stakeholders  identified  by  the  systems  engineers  in  the  initial 
phases  was  complete  and  everyone’s  vision  was  captured  in  the  design.  If  this  was 
true  it  is  possible  that  the  system  will  be  accepted  by  the  stakeholders.  Otherwise 
some  of  them  may  view  it  negatively. 
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The  operational  phase  occurs  simultaneously  with  the  maintenance  phase.  The 
maintainers  are  the  main  stakeholders  in  this  phase.  These  are  the  Base  and  Squadron 
level  maintainers  but  the  technicians  involved  with  the  repair  of  the  system  at  the 
manufacturer’s  depot  facilities  can  also  be  considered  stakeholders. 

The  CAF  maintainers’  vision  of  the  system  at  this  phase  is  that  it  is  a  highly 
reliable  system  which  performs  all  the  functions  they  initially  requested.  They  would 
like  the  system  to  be  easy  to  maintain  (i.e.  to  experience  a  low  number  of  failures, 
to  require  small  amount  of  teardown  to  gain  access  for  repair,  and  to  require  a  small 
amount  of  downtime).  Self-diagnostics  capabilities  of  the  system  are  viewed  as  a 
highly  desirable  feature. 

The  manufacturer’s  technical  personnel  have  similar  expectations  from  the  ISHMS. 
They  would  like  the  system  to  experience  few  serious  failures  that  require  their  inter¬ 
vention.  In  case  some  of  the  system’s  components  are  sent  to  them  for  repair,  they 
would  expect  that  the  necessary  testing  and  repair  equipment  is  available  and  the 
repairs  feasible. 

As  the  system  stays  longer  in  operation,  the  need  for  some  improvements  or 
upgrades  may  arise.  This  need  may  be  created  by  the  feedback  provided  to  the  devel¬ 
opers  and  manufacturers  from  the  operators.  These  groups  are  the  main  stakeholders 
in  this  phase. 

The  developers  envision  a  system  that  will  operate  smoothly  throughout  its 
design  life.  However,  after  the  system  has  been  deployed  and  put  into  operation  there 
might  be  problems  they  did  not  anticipate.  In  order  to  be  able  to  deal  with  these 
problems,  the  developers  would  like  to  receive  frequent  and  accurate  feedback  from  the 
operators.  Therefore,  they  would  like  to  have  a  communications  scheme  to  permit  this 
information  to  flow  back  and  forth  from  the  field  back  to  them.  Also,  they  envision  the 
ISHMS  as  a  system  that  can  perform  self-diagnosis  and  provide  accurate  data  about 
its  condition.  Thus  the  feedback  from  the  field  can  be  automated  and  independent 
of  the  maintainers.  The  improvements  during  this  phase  should  consist  of  software 
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upgrades  and  modifications  of  parts  due  to  obsolescence.  Their  initial  design  should 
be  as  complete  as  possible  so  that  these  modifications  are  not  extensive. 

The  manufacturers  would  like  to  produce  a  system  that  will  require  a  mini¬ 
mal  amount  of  refinement  during  its  lifetime.  The  costs  they  will  have  to  incur  for 
these  refinements  should  be  kept  at  a  low  level.  Many  refinements  translate  for  the 
manufacturers  into  resources  committed  to  the  support  of  the  system.  Also,  many 
modifications  and  upgrades  are  perceived  by  the  customers  as  quality  problems  and 
hurt  the  manufacturers’  reputation. 

The  CAF  maintainers,  also,  would  like  the  system  to  operate  without  the  need 
for  major  modifications.  Very  often  the  modifications  on  a  system  mean  additional 
downtime.  The  maintainers  view  the  system  as  a  solution  to  the  problem  of  increased 
downtime  due  to  structural  inspections  on  the  A-37  aircraft;  they  would  not  like  a 
new  source  of  downtime  to  be  installed  on  their  aircraft. 

In  the  final  phase  of  the  system’s  life-cycle,  the  main  stakeholders  are  again  the 
country’s  Ministry  of  National  Defense  and  the  CAF.  Other  stakeholders  the  team 
identified  for  this  phase  are  the  manufacturers  and  the  regulatory  agencies. 

For  the  purpose  of  our  analysis,  the  thesis  team  assumed  that  the  life  of  the 
ISHMS  will  be  at  least  as  long  as  the  remaining  life  of  the  A-37  aircraft  (i.e.  the 
ISHMS  will  not  be  retired  before  the  A-37’s  are).  As  the  ISHMS  (and  the  A-37 
aircraft)  reaches  its  design  life  a  new  problem  arises  for  the  Ministry  of  National 
Defense  and  the  CAF.  The  problem  is  how  will  the  system  be  retired  and  disposed, 
and  how  will  the  lost  capabilities  be  replaced. 

Both  these  stakeholders  will  need  to  develop  a  plan  for  the  retirement  of  the 
system.  If  the  system  has  still  remaining  useful  life  could  it  be  removed  from  the 
retired  aircraft  and  used  on  other  aircraft?  Could  it  be  sold  to  another  operator  who 
could  still  use  it?  Is  the  system  completely  useless  and  needs  to  be  discarded?  Are 
there  any  restrictions  in  the  disposal  of  the  system?  These  are  some  of  the  questions 
that  need  to  be  answered  by  the  stakeholders.  The  CAF  as  the  customer  would  prefer 
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the  retirement  and  the  disposal  of  the  system  to  have  as  little  effect  as  possible  in  its 
operations. 

The  manufacturers  are  another  group  of  stakeholders  in  this  phase.  Very  often 
they  are  involved  in  the  disposal  of  their  products.  They  have  to  make  sure  that  the 
requirements  of  another  stakeholder,  the  regulatory  agencies,  for  this  phase  are  being 
met. 


4-4  Operational  Concept 

As  the  thesis  team  discussed  in  chapter  3,  the  development  of  the  operational 
concept  for  the  ISHMS  will  be  done  by  creating  sets  of  scenarios  for  the  life-cycle 
phases  of  the  system.  The  purpose  of  these  scenarios  will  be  to  describe  the  view  of 
the  main  stakeholders  and  its  interaction  with  the  system  at  the  different  phases  of 
the  system’s  life-cycle.  The  focus  in  these,  relatively  simple,  scenarios  is  on  what  the 
stakeholders  and  the  system  are  doing  and  not  how  this  is  being  done. 

For  the  first  two  phases  identification  of  need  and  concept  definition  the  thesis 
team  developed  scenarios  that  applied  to  both  of  them.  The  reason  is  that  in  the  first 
phase,  as  the  thesis  team  already  mentioned,  the  system  exists  only  as  a  vague  idea 
in  the  mind  of  the  stakeholders;  this  idea  starts  taking  shape  in  the  second  phase. 

Scenario:  The  systems  engineers  identify  the  stakeholders  for  the  first  phase 
of  the  system.  The  systems  engineers  enter  the  customer’s  environment  and  get  a 
clear  understanding  of  the  customer’s  needs  and  how  they  will  use  the  system.  They 
prepare  and  discuss  with  these  stakeholders  a  concept  for  the  system.  Agreement  is 
achieved  among  the  stakeholders  on  the  proposed  concept.  The  systems  engineers 
continue  the  development  in  the  next  phase. 

Scenario:  The  systems  engineers  try  to  identify  the  stakeholders  for  the  first 
phase  of  the  system.  The  CAF  Flight  Safety  agencies  are  not  identified  as  stakehold¬ 
ers.  The  proposed  concept  does  not  include  the  views  and  requirements  of  the  Flight 
Safety  agencies.  Agreement  cannot  be  achieved  among  the  stakeholders.  The  system 
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engineers  revise  the  stakeholders  to  ensure  all  involved  groups  are  represented  in  the 
operational  concept  of  the  system. 

For  the  next  phase  the  preliminary  design  a  possible  scenario  describing  what 
the  system  and  the  stakeholders  do  is  as  follows: 

Scenario:  The  systems  engineers  develop  the  Systems  Engineering  Plan  (SEP) 
and  define  the  “who,  what,  when,  where,  why,  and  how  of  the  applied  SE  approach” 
[23].  They  develop  the  integrated  master  plan  and  schedules  as  well  as  the  technical 
performance  measures.  They  organize  system  engineering,  design  and  integration 
teams  and  define  detailed  roles  for  their  members.  At  the  same  time,  they  translate  the 
operational  concept  into  the  users’  requirements  and  develop  the  system  architectures. 

Scenario:  The  systems  engineers  develop  the  SEP.  They  develop  the  integrated 
master  plan  and  schedules  as  well  as  the  technical  performance  measures.  They 
organize  system  engineering,  design  and  integration  teams  but  the  responsibilities  and 
the  roles  of  the  integration  team  are  not  explicitly  defined.  This  omission  results  in 
miscommunication  between  the  teams  and  reporting  problems  in  subsequent  phases. 

In  the  next  phase  detailed  configuration  item  design  a  possible  scenario  unfolds 
as  follows: 

Scenario:  The  system  design  team  develops  the  configuration  item  list  and  the 
design  for  each  item.  The  integration  plan  and  verification-validation  requirements 
are  defined.  The  physical  solution  of  the  system  takes  shape  as  the  designers  are 
considering  the  technologies  that  are  going  to  be  used.  The  configuration  items’  design 
is  influenced  by  the  requirements  set  by  the  manufacturers,  who  are  also  involved 
during  this  phase. 

A  possible  scenario  for  the  final  phase  of  the  development  period,  the  system 
integration ,  is  the  following: 

Scenario:  A  prototype  of  the  system  is  built.  The  integration  of  this  prototype 
proceeds  as  planned.  During  the  validation  testing  the  designers  identify  that  some 
of  the  requirements  were  not  addressed  satisfactorily.  The  design  team  reviews  the 
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design  of  the  unsatisfactory  configuration  items.  The  validation  tests  are  revised  to 
reflect  the  design  changes.  The  validation  is  successful  and  the  design  is  approved  for 
production. 

In  the  production  phase  the  manufacturers  (contractors)  and  the  CAF  engineers 
and  acquisition  officers  are  the  main  stakeholders. 

Scenario:  The  manufacturers  get  into  contract  with  the  CAF,  develop  a  produc¬ 
tion  plan,  acquire  the  special  equipment  needed  for  the  new  production  line,  contract 
suppliers  for  the  required  parts  and  begin  production.  CAF  engineers  are  checking 
periodically  the  production  progress.  The  production  proceeds  as  planned  and  the 
systems  are  completed  in  time. 

Scenario:  The  manufacturers  get  into  a  contract  with  the  CAF,  develop  a  pro¬ 
duction  plan,  acquire  the  special  equipment  needed  for  the  new  production  line,  con¬ 
tract  suppliers  for  the  required  parts  and  begin  production.  The  suppliers  cannot 
meet  the  delivery  schedule.  This  situation  causes  delays  in  the  ISHMS  production. 
CAF  engineers  and  acquisition  officers  are  dissatisfied.  The  manufacturer  is  trying 
to  find  other  supply  sources  while  renegotiating  the  ISHMS  production  plan  with  the 
Air  Force. 

As  the  production  of  the  first  systems  goes  towards  completion  the  training 
phase  begins. 

Scenario:  The  CAF  training  agencies  and  the  manufacturer’s  training  division 
agree  on  a  training  schedule  for  the  customer’s  personnel.  They  decide  that  the 
training  will  take  place  at  the  manufacturer’s  facilities.  Training  courses  are  developed 
for  each  group  of  operators  (i.e.  maintainers,  pilots,  etc.)  The  training  facility  is 
arranged  and  a  dummy  system  is  built  for  educational  purposes.  The  training  starts 
and  proceeds  according  to  the  schedule.  The  CAF  operators  are  satisfied  with  the 
level  of  knowledge  and  practical  application  provided. 

Scenario:  The  CAF  training  agencies  and  the  manufacturer’s  training  division 
agree  on  a  training  schedule  for  the  customer’s  personnel.  They  decide  that  the 
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training  will  take  place  at  the  customer’s  facilities.  The  training  material  and  aids  will 
be  developed  and  provided  by  the  manufacturer;  different  courses  are  developed  for 
each  group  of  operators  (i.e.  maintainers,  pilots,  etc.)  The  training  facility  is  arranged 
and  a  dummy  system  is  built  for  educational  purposes.  The  training  begins  but  the 
trainees  consider  the  knowledge  provided  to  them  inadequate.  The  manufacturer’s 
personnel  revise  the  training  material  and  the  schedule.  The  training  is  completed 
with  a  delay  that  causes  the  system  deployment  schedule  to  slip  behind. 

Scenario:  The  manufacturer’s  personnel  and  the  CAF  training  agencies  come 
to  agreement  for  the  provision  of  training  in  the  next  years  after  the  deployment. 

During  the  deployment  phase  the  main  stakeholders  are  the  CAF  and  the  man¬ 
ufacturers.  Some  scenarios  describing  this  phase  are  the  following: 

Scenario:  A  deployment  plan  is  arranged  between  the  CAF  agencies  and  the 
manufacturer.  The  location  of  the  system  installation,  the  equipment  required,  the 
task  performance  (who  is  going  to  do  what),  and  the  time  schedule  are  defined.  The 
deployment  proceeds  according  to  the  schedule.  The  system  is  delivered  and  accepted 
on  time. 

Scenario:  A  deployment  plan  is  arranged  between  the  CAF  agencies  and  the 
manufacturer.  The  location  of  the  system  installation,  the  equipment  required,  the 
task  performance  (who  is  going  to  do  what),  the  time  schedule  are  defined.  As  the 
installation  of  the  system  on  the  first  aircraft  is  completed  and  the  CAF  personnel 
performs  the  acceptance  inspection,  system  operation  problems  are  revealed.  The 
manufacturer’s  engineering  department  is  involved  and  is  trying  to  find  a  solution. 
The  deployment  schedule  slips.  The  cause  of  the  problem  is  traced  to  the  production 
phases.  The  manufacturer  comes  up  with  a  solution  and  the  deployment  resumes. 

Scenario:  A  deployment  plan  is  arranged  between  the  CAF  agencies  and  the 
manufacturer.  The  location  of  the  system  installation,  the  equipment  required,  the 
task  performance  (who  is  going  to  do  what),  and  the  time  schedule  are  defined.  As 
the  installation  of  the  system  on  the  first  aircraft  begins  problems  are  revealed.  The 
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manufacturer’s  engineering  department  is  involved  and  is  trying  to  find  a  solution. 
The  problems  are  traced  to  the  design  phase.  The  designers  are  involved  while  the 
deployment  is  cancelled.  The  designers  find  a  solution  to  the  problem.  The  production 
of  the  redesigned  parts  starts  and  the  deployment  resumes  after  a  long  delay. 

Once  the  deployment  is  completed  the  operation  phase  begins.  The  CAF  and 
the  country’s  Ministry  of  Defense  are  the  main  stakeholders  in  the  phase  who  are 
expecting  the  system  to  relieve  their  problem. 

Scenario :  The  A-37  aircraft  start  flying  with  the  ISHMS  installed.  The  system 
functions  as  designed  and  as  desired.  The  monitoring  of  the  cracks  and  the  corrosion 
is  continuous;  the  data  acquired  from  the  system  are  accurate.  The  analysis  per¬ 
formed  at  the  ground  workstation  helps  the  engineers  to  assess  the  individual  aircraft 
condition.  The  warnings  generated  for  some  aircraft  prove  to  be  accurate.  After  a 
short  period  of  data  collection  a  customized  inspection  plan  for  each  aircraft  is  gen¬ 
erated.  The  engineers’  assessment  of  the  fleet’s  condition  allows  them  to  develop  a 
plan  for  the  service  life  extension.  The  customized  inspections  have  shorter  duration 
while  the  components  needing  replacement  are  significantly  reduced.  The  A-37  fleet 
availability  increases  to  the  desired  level. 

Scenario:  The  A-37  aircraft  start  flying  with  the  ISHMS  installed.  The  sys¬ 
tem’s  operations  is  not  as  desired.  The  monitoring  of  the  cracks  and  the  corrosion  is 
problematic ;  the  data  acqiiired  from  the  system  are  very  often  corrupted.  The  analysis 
performed  at  the  ground  workstation  creates  difficulties  to  the  engineers  in  assessing 
the  individual  aircraft’s  condition.  The  warnings  generated  for  some  aircraft  prove 
to  be  inaccurate.  Maintenance  is  performed  based  on  the  ISHMS  indications,  which 
proves  to  be  unnecessary.  The  engineers’  assessment  of  the  fleet’s  condition  does  not 
allow  them  to  extend  the  A-37  aircraft  service  life.  The  maintainers  are  still  per¬ 
forming  the  structural  inspections.  As  a  result  the  anticipated  improvement  in  the 
aircraft  availability  is  not  achieved.  The  maintenance  and  operations  agencies  are 
dissatisfied.  The  manufacturers  and  the  designers  are  investigating  the  root  cause  of 
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these  functional  problems.  The  development  of  a  corrective  action  is  time  consuming 
and  creates  additional  problems  to  all  stakeholders. 

Simultaneously  with  the  operation  phase  begins  the  maintenance  phase.  The 
main  stakeholders  now  are  the  CAF  maintenance  groups. 

Scenario:  After  the  completion  of  the  system  installation  begins  its  operational 
use.  There  are  no  effects  caused  by  the  ISHMS  to  other  aircraft  systems.  The  number 
of  system  failures  is  small  and  the  maintainers  involved  with  its  maintenance  are 
satisfied.  They  believe  that  the  troubleshooting  and  repair  procedures  developed 
by  the  manufacturer  are  effective,  and  the  training  provided  to  them  adequate  to 
maintain  the  system. 

Scenario:  After  the  completion  of  the  system  installation  begins  its  operational 
use.  The  maintainers  involved  with  its  maintenance  are  dissatisfied.  They  believe  that 
the  troubleshooting  procedures  are  inadequate  and  the  system  is  difficult  to  maintain 
(i.e.  components  are  hard  to  reach,  a  lot  of  teardown  required).  The  downtime  caused 
by  the  ISHMS  failures  is  significant.  The  manufacturer’s  personnel  are  involved  and 
are  trying  to  improve  the  troubleshooting  procedures. 

Scenario:  As  the  system  goes  into  operation  and  starts  experiencing  failures  the 
CAF  Logistics  agencies  realize  that  its  support  is  not  an  easy  task.  The  parts  ordering 
system  is  ineffective  with  long  lead  times  and  delays.  The  cost  of  the  replacement  parts 
is  also  high.  These  delays  create  problems  in  the  support  provided  to  the  maintainers, 
while  the  high  costs  put  pressure  on  the  budget. 

As  more  experience  from  the  system’s  operations  is  accumulated  the  need  for 
some  improvements/modiheations  may  arise.  This  happens  in  the  refinement  phase. 

Scenario:  The  data  collected  from  the  ISHMS  are  analyzed  and  feedback  is 
sent  to  the  manufacturers  and  the  designers.  The  system  operates  as  designed  and 
no  further  refinement  is  required. 

Scenario:  The  maintainers  send  feedback  from  the  system  operation  to  the  man¬ 
ufacturer.  The  manufacturer  improves  the  ISHMS  analysis  algorithm  and  organize 
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in  coordination  with  the  operator  an  upgrade.  The  operators  expect  this  upgrade  to 
have  minimal  effect  in  the  operational  use  of  the  aircraft. 

Scenario:  Some  of  the  ISHMS  parts  supplied  from  commercial  sources  become 
obsolete.  The  manufacturer  identifies  the  need  for  a  modification  to  the  system  in 
order  to  replace  the  obsolescent  parts.  New  supply  sources  are  selected.  The  man¬ 
ufacturer  is  trying  to  use  replacement  parts  that  are  expected  to  have  longer  life. 
The  modification  of  the  system  is  organized  in  coordination  with  the  operators  and 
executed  by  a  manufacturers’  field  team.  Additional  training  is  required  for  the  CAF 
maintainers  on  the  new  ISHMS  configuration  after  the  modification. 

Finally  in  the  retirement  phase  the  CAF  and  the  country’s  Ministry  of  Defense 
are  the  main  stakeholders.  The  following  scenarios  describe  their  involvement  with 
the  system  in  this  phase. 

Scenario:  As  the  ISHMS  is  approaching  the  end  of  its  design  life  the  CAF 
engineers  must  evaluate  the  situation  and  make  a  recommendation  for  the  actions 
that  will  follow.  They  develop  a  plan  for  the  retirement  of  the  system.  They  examine 
the  regulatory  restrictions  in  order  to  ensure  that  the  system’s  disposal  will  not  create 
any  conflict  with  the  regulatory  agencies.  The  schedule  is  followed  and  the  system 
goes  out  of  service. 

Scenario:  The  CAF  engineers  determine  that  the  A-37  aircraft  must  be  retired. 
However,  the  ISHMS  has  still  remaining  useful  life.  Arrangements  with  the  manufac¬ 
turer  are  made  to  purchase  the  retired  (i.e.  no  longer  needed  for  the  CAF)  systems. 
The  manufacturer  can  upgrade  and  resell  these  systems  to  another  customer. 

Scenario:  As  the  ISHMS  is  approaching  the  end  of  its  design  life  the  CAF  en¬ 
gineers  must  evaluate  the  situation  and  make  a  recommendation  for  the  actions  that 
will  follow.  They  develop  a  plan  for  the  retirement  of  the  system.  They  agree  with 
the  manufacturer  to  carry  out  the  disposal  of  the  retired  systems.  As  the  manufac¬ 
turer  is  trying  to  dispose  the  systems  they  realize  that  there  is  a  conflict  with  the 
environmental  regulations  due  to  toxic  material  contained  in  the  ISHMS  parts.  The 
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manufacturer  is  searching  for  a  solution  to  neutralize  the  toxic  substances  and  dispose 
the  retired  systems. 

The  results  of  the  SE  requirements  process  are  presented  in  the  following  sec¬ 
tion.  A  structured  process  seven  step  approach  is  used.  User  provided  originating 
requirements  allow  the  methodical  discovery  and  refinement  of  the  ISHMS  require¬ 
ments. 

4-5  Requirements  Results 

Manpower  intensive  300  hour  periodic  maintenance  inspections  were  driving  up 
the  cost  of  operating  Cessna  A-37  legacy  aircraft  beyond  original  safe  life  [41].  Buede’s 
structured  method  of  requirements  definition  was  used  to  develop  the  originating  and 
derived  requirements  for  the  A-37  ISHMS  to  reduce  this  maintenance  cost  while  main¬ 
taining  SOF.  The  structured  method  for  creating  the  ISHMS  requirements  involved 
a  seven  step  approach. 

The  first  step  developed  the  A-37  ISHMS  operational  concept.  The  ISHMS 
operational  concept  was  the  general  vision  of  the  system,  a  statement  of  capability 
requirements,  and  how  the  system  was  expected  to  be  used  (Figure  3.4).  The  user 
provided  the  operational  concept  with  a  series  of  originating  requirements. 

4-5.1  Vision.  The  generic  Major  Command  Headquarters  needed  an  inte¬ 
grated  system  that  reduces  the  cost  of  safely  operating  Cessna  A-37  legacy  aircraft 
beyond  design  safe  life. 

4-5.2  Originating  Requirements.  The  implementation  of  an  ISHMS  will  re¬ 
duce  the  current  aircraft  inspection  burden  on  the  maintainers.  The  burden  shall  be 
reduced,  not  necessarily  all  inclusive,  by  increasing  the  mean  time  between  inspec¬ 
tions,  decreasing  mean  time  to  inspect,  and/or  decreasing  number  of  inspection  items, 
as  well  as  reducing  the  risk  of  damage  due  to  performing  the  inspections.  Ideally,  such 
system  will  alert  the  user  of  current  and/or  impending  aircraft  structural  health  fail- 
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ures.  The  system  shall  be  reliable  and  accurate  such  that  it  does  not  adversely  impact 
aircraft  safety  or  maintenance.  The  addition  of  the  system  should  maintain  the  SOF 
within  the  allowable  parameters.  Ideally,  the  addition  of  the  ISHMS  should  not  re¬ 
duce  the  performance  nor  impose  restrictions  on  the  operational  limits  of  the  aircraft. 
The  presence  of  the  system  on  the  aircraft  should  not  limit  the  use  of  the  aircraft  in 
current  and  anticipated  operational  environments.  The  total  life-cycle  cost  (develop¬ 
ment,  acquisition,  installation,  operating/maintenance,  and  disposal)  of  the  ISHMS 
should  not  exceed  the  total  aircraft  maintenance  costs  (inspections  and  repairs)  of  the 
structural  components  being  monitored  by  the  ISHMS  for  the  extended  service-life 
period.  The  average  A-37  fleet  flight  hours  are  5958  (Figure  4.7). 

The  estimated  A-37  aircraft  design  life  is  8000  flight  hours  allowing  the  aircraft 
to  operate  up  to  10,000  total  flight  hours  (8  years  of  additional  usage).  The  impact  to 
aircraft  availability  shall  be  reduced,  when  possible,  by  installing  the  ISHMS  during 
scheduled  aircraft  downtime.  Additionally,  the  need  for  specialized  tools  or  additional 
support  equipment  should  be  kept  to  a  minimum.  The  ISHMS  should  have  a  low  mean 
time  to  repair  and  a  high  mean  time  between  failures.  System  calibration  should  be 
required  no  more  than  once  annually.  Once  installed,  the  system  should  be  easily 
accessible  for  maintenance  purposes.  Additionally,  maintenance  of  the  ISHMS  should 
not  induce  damage  to  the  aircraft.  The  system  will  include  an  internal  component 
failure  test,  i.e.  self-test.  The  system  design  life  should  exceed  twice  the  remaining 
expected  aircraft  life.  The  system  should  not  require  hazardous  material  handling 
nor  disposal.  Minimize  ISHM  integration  with  current  legacy  aircraft  subsystems.  As 
much  as  possible,  the  ISHM  system  shall  be  self  contained  with  minimum  connections 
to  aircraft  avionics  and  power. 

4-5.3  Expectation  of  Use.  The  system  should  be  intuitive  and  easy  to 
operate.  System  data  should  be  available  and  formatted  such  that  it  can  be  analyzed 
efficiently  and  easily  at  any  maintenance  or  operating  location.  Any  generated  data 
will  be  archived  in  an  external  system  and  retrievable  at  a  later  time.  Structural  health 
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Figure  4.7:  CAF  A-37  Flight  Hour  Distribution 
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data  will  be  used  for  extending  time  between  inspections  and  facilitate  planning. 
Industry  standards  for  hardware  connections  and  data  formatting  should  be  used. 

The  second  step  was  the  definition  of  the  system  boundary  with  an  external 
systems  diagram.  A  context  diagram  was  created  to  distinguish  the  ISHMS  boimdary 
from  the  external  systems  (Figure  4.8). 


The  third  step  was  the  development  of  the  weighted  objectives  hierarchy  and 
performance  indices  (Appendix  C).  This  hierarchy  defined  cost,  schedule,  and  perfor¬ 
mance  goals  the  stakeholders  required  for  an  acceptable  system  design  (Figure  4.9). 

The  fourth  step  of  developing,  analyzing  and  refining  the  requirements  required 
taking  the  operational  concept,  system  inputs  and  outputs,  and  combined  with  the 
objectives  hierarchy  to  refine  the  originating  requirements  into  the  system  require¬ 
ments. 
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Figure  4.9:  ISHMS  Objectives  Hierarchy 
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4-5-4  System  Requirements. 


1.  Extend  Service  Life 

2.  Reduce  Inspection  Burden 

3.  Reduce  Inspection  Induced  Damage 

4.  Maintain  Safety  of  Flight 

5.  Reduce  Cost 

6.  Collect  Data  in  Real  Time 

7.  Minimize  Impact  on  Aircraft  Operations 

8.  Easy  to  Maintain 

9.  Easy  to  Use  Pilot  and  Maintenance  Cuing 

10.  Minimize  Development  and  Installation  Time 

11.  Streamline  Acquisition 

The  fifth  step  was  to  ensure  the  requirements  feasibility.  Feasibility  was  deter¬ 
mined  if  the  requirement  was  verifiable  with  demonstration,  analysis  and  simulation, 
inspection,  or  instrumented  test. 

4-5.5  Requirements  Feasibility.  The  Extend  Service  Life  requirement  was 
observed  by  analysis  and  simulation  utilizing  structural  finite  element  analysis  to 
predict  crack  growth  with  operations  for  an  additional  5000  flight  hours  beyond  design 
life. 

The  Reduce  Inspection  Burden  requirement  was  observed  by  analysis  and  sim¬ 
ulation  utilizing  the  structural  metamodel  with  a  Monte  Carlo  simulation  to  predict 
feasibility  of  extending  300  flight  hour  inspections  to  a  600  hour  inspection  interval. 

The  Reduce  Inspection  Induced  Damage  requirement  was  observed  by  analysis 
and  simulation  tabulating  the  difference  in  number  of  inspections  from  the  baseline 
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to  the  extended  inspection  interval  with  the  ISHMS.  The  reduction  in  the  number  of 
inspections  correlates  to  a  reduction  in  the  amount  of  inspection  induced  damage. 

The  Maintain  Safety  of  Flight  requirement  was  observed  by  analysis  and  simula¬ 
tion  comparing  the  single  flight  hour  probability  of  fracture  of  the  baseline  inspection 
interval  versus  the  extended  inspection  interval  with  the  ISHMS  installed.  Both  val¬ 
ues  were  compared  to  the  USAF  standard  of  1CT' .  The  crack  probability  of  detection 
of  the  ISHMS  was  observed  by  instrumented  test. 

The  Reduce  Cost  requirement  was  observed  by  analysis  and  simulation  compar¬ 
ing  the  difference  in  the  number  of  300  hour  inspections  of  the  baseline  versus  the 
status  quo  multiplied  by  the  expected  cost  of  the  inspection. 

The  Collect  Data  in  Real  Time  requirement  was  observed  by  analysis  and  simu¬ 
lation  utilizing  finite  element  analysis  dynamic  model  to  predict  the  modal  frequencies 
of  the  A-37  wing. 

The  Minimize  Impact  on  Aircraft  Operations  requirement  was  observed  by  in¬ 
strumented  test  of  the  modified  system  during  environmental  and  acceptance  testing. 

The  Easy  to  Maintain  requirement  was  observed  by  demonstration  during  ac¬ 
ceptance  testing. 

The  Easy  to  Use  Pilot  and  Maintenance  Cuing  requirement  was  observed  by 
demonstration  of  maintenance  personnel  using  the  system  and  instrumented  test  of 
the  pilot  cuing  function. 

The  Minimize  Development  and  Installation  Time  requirement  was  observed  by 
inspection  of  the  system  design. 

The  Streamline  Acquisition  requirement  was  observed  by  inspection  of  the  ISHMS 
design. 

The  sixth  step  was  defining  the  qualification  system  requirements.  The  sys¬ 
tem  qualification  involved  establishing  the  requirements  to;  validate  the  operational 
concept,  verify  the  components  &  system,  validate  the  system,  and  accept  the  system. 
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4-5.6  Qualification  Requirements.  Extend  Service  Life  ISHMS  will  extend 
operation  of  A-37  service  life  beyond  original  design  life  of  5000  flight  hours. 

Reduce  Inspection  Burden  ISHMS  should  reduce  operations  and  maintenance 
cost  by  extending  300  hour  inspections  to  600  hour  intervals. 

Reduce  Inspection  Induced  Damage  The  ISHMS  shall  reduce  overall  number  of 
inspections  proportionally  reducing  inspection  induced  damage  from  disassembly  and 
inspection. 

Maintain  Safety  of  Flight  The  single  flight  hour  probability  of  fracture  should 
not  exceed  the  USAF  standard  of  10~'.  The  fleet  total  probability  of  fracture  should 
not  exceed  1  in  103  [65] .  The  crack  detection  ability  of  the  ISHM  system  should  meet 
or  exceed  the  USAF  standard  of  90%  detection  with  95%  confidence.  The  ISHMS 
should  notify  maintenance  and  operations  personnel  of  impending  failure  prior  to 
fracture. 

Reduce  Cost  ISHMS  must  produce  cost  avoidance  greater  than  the  development, 
installation,  and  operation  cost  of  the  ISHMS. 

Collect  Data  in  Real  Time  ISHMS  should  collect  crack  growth  data  in  real  time 
at  a  Inquest  rate  of  at  least  4.034  Hz  to  enable  the  capture  of  bending  vibration  effects 
on  crack  growth.  ISHMS  should  have  capability  to  store  greater  than  600  flight  hours 
of  sensor  readings. 

Minimize  Impact  on  Aircraft  Operations  Installation  and  operation  of  the  ISHMS 
should  provide  a  less  than  10%  impact  on  aircraft  performance  (weight,  max  speed, 
etc).  The  ISHMS  modification  should  not  impact  aircraft  operational  requirements. 
The  ISHMS  should  not  reduce  the  number  and  types  of  mission  prohles  flown.  The 
ISHMS  impact  to  mission  capability  should  be  minimized  by  installation  during  sched¬ 
uled  maintenance,  depot,  or  300  hour  inspection  periods.  ISHMS  should  not  reduce 
the  mission  capable  rate  due  to  system  reliability  during  operation.  The  ISHMS 
should  operate  in  all  environments  from  -30  to  200  degrees  Fahrenheit. 
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Easy  to  Maintain  The  ISHMS  should  be  easy  to  maintain  with  a  Mean  Time 
Between  Failures  aligned  with  projected  depot  schedule  of  once  every  five  years.  Mean 
Time  To  Repair  should  be  should  be  minimized  by  maximizing  the  use  of  Line  Re¬ 
placeable  Units  (LRU)  in  the  ISHMS.  The  LRUs  should  be  as  easily  accessible  as 
the  current  A-37  avionics  subsystems.  The  24  hour  fix  rate  should  be  greater  than 
80%.  The  system  should  be  easy  to  maintain  without  specialized  tools  and  Material 
Handling  Equipment.  Periodic  maintenance  of  the  system  should  also  be  minimized 
by  restricting  calibration  by  Test  Measurement  and  Diagnostic  Equipment  to  no  more 
than  once  annually.  The  ISHMS  should  also  include  a  self  diagnosis  function  to  verify 
the  status  of  the  sensors,  wiring,  multiplexing,  pilot  cuing,  and  data  storage. 

Easy  to  Use  Pilot  and  Maintenance  Cuing  The  ISHMS  should  be  easy  to  use 
by  novice  3-level  maintenance  personnel.  There  should  be  no  more  than  3  steps  to  re¬ 
trieve  the  crack  growth  data  from  the  A-37  aircraft.  The  data  should  be  automatically 
analyzed  resulting  in  user  friendly  outputs  of  flight  hours  remaining  until  maintenance 
required.  The  ISHMS  should  be  based  on  a  2-level  maintenance  concept  with  flight 
line  maintenance  troubleshooting  the  system  and  replacing  LRUs.  The  ISHMS  tasks 
should  be  easily  trained  with  the  standard  tasks  of  downloading,  uploading  and  inter¬ 
preting  the  crack  growth  data  taking  no  more  than  10  steps  to  accomplish.  The  crack 
growth  data  should  auto  archive  compiled  data  and  make  it  available  for  a  period 
of  5  years.  The  ISHMS  should  provide  instant  pilot  cuing  indicating  crack  growth  is 
approaching  structural  failure. 

Minimize  Development  and  Installation  Time  The  ISHMS  integration  with  cur¬ 
rent  aircraft  subsystems  should  be  minimized  to  reduce  the  effect  on  aging  wiring  and 
reduce  requalification  testing  of  the  A-37  aircraft.  The  ISHMS  should  be  self  powered 
with  no  requirement  for  aircraft  power.  The  ISHMS  should  not  connect  to  the  aircraft 
electrical  system.  The  modification  time  and  cost  should  be  minimized  to  expedite 
installation  of  the  ISHMS  on  the  A-37  aircraft.  ISHMS  install  shall  be  accomplished 
in  coordination  with  current  scheduled  maintenance  activities  to  minimize  the  impact 
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on  aircraft  availability.  Expertise  required  to  install  the  ISHMS  should  be  no  greater 
than  that  of  a  contractor /depot  field  team. 

Streamline  Acquisition  The  ISHMS  design  life  should  be  greater  than  the  pro¬ 
jected  remainder  of  A-37  aircraft  life  (i.e.  4000  flight  hours).  ISHMS  should  uti¬ 
lize  commercial  connections  and  industry  standards  wherever  practical.  The  ISHMS 
should  not  significantly  increase  the  hazardous  waste  disposal  requirement  of  the  A-37 
aircraft.  Finally,  the  basic  system  design  should  be  general  enough  to  use  on  other 
aircraft. 

The  seventh  and  final  step  was  obtaining  the  sponsor  approval  of  the  require¬ 
ments.  The  primary  sponsor  was  unavailable  so  the  requirements  were  validated 
through  thesis  advisors,  AFRL,  and  SAF /IARL. 

The  results  of  the  SE  process  architecture  products  are  presented  in  the  fol¬ 
lowing  section.  Decomposition  of  the  requirements  into:  inputs,  outputs,  controls, 
mechanisms,  and  functions  forms  the  basis  of  the  architectures. 

4-6  DoDAF  Architectures 

In  Chapter  3  the  team  discussed  what  are  system  architectures,  their  impor¬ 
tance,  and  the  methodology  used  to  develop  the  architecture  products.  During  this 
section  of  Chapter  4,  the  architecture  products  will  be  presented  along  with  a  brief 
description  on  the  development  process  for  each.  Most  architecture  products  were 
created  using  the  System  Architect  software  known  as  Popkin.  There  are  a  number  of 
existing  computer-aided  system  engineering  software  tools  that  facilitate  architecture 
development.  For  example,  the  software  package  known  as  CORE  is  very  popular 
among  the  SE  community  for  its  ease  in  the  creation  of  IDEFO  diagrams.  However, 
the  thesis  team  decided  to  use  the  Popkin  software  because  it  has  built-in  rules  for 
creating  most  of  the  DoDAF  architecture  products,  thus  simplifying  significantly  the 
whole  architecture  design  process. 
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4-6.1  All-Views  Architectures.  The  first  products  required  by  DoDAF  were 
the  AV-1  and  AV-2,  which  are  not  exactly  architectures,  but  rather  textual  definitions 
and  description  of  the  problem,  purpose  and  scope  of  the  architecture  products  to 
follow.  Basically,  the  AV-1  places  the  boundaries  of  the  architecture  and  is  depicted 
in  Figure  4.10.  The  AV-2,  also  known  as  the  Integrated  Data  Dictionary,  is  a  glossary 
with  definitions  of  terms  used  in  the  architectures.  For  the  most  part,  each  item  in 
the  graphical  architectures  has  an  entry  in  the  AV-2,  which  is  presented  in  Appendix 
B. 


Identification 

Architecture  Title:  ISHMS  Requirements  Identification 

Architects:  AFIT  GSE-06M,  Section  1,  ISHMS  Thesis  Group 

Purpose 

Problem  Description :  aging  aircraft  are  approaching  or  exceeded  the  end  of  their  design  life; 
users  want  to  safely  extend  the  life  of  these  aircraft  while  minimizing  the  downtime  due  to 
inspections  and  maintenance;  a  low-cost  integrated  structural  health  monitoring  system 
that  provides  at  near  real-time  feedback  has  been  identified  as  the  potential  solution. 

Purpose:  to  apply  the  systems  engineering  approach  to  the  process  of  requirements 
identification  for  the  development  and  acquisition  of  an  ISHMS  for  aging  aircraft 

Scope:  This  architecture  depicts  broad  ISHMS  requirements  and  information  exchanges 

Figure  4.10:  AV-1  Architecture 

4-6.2  Operational  Architectures. 

4-6.2. 1  OV-1:  Archi-toon.  The  first  architecture  product  the  thesis 

team  produced  is  the  OV-1,  also  known  as  the  archi-toon.  The  OV-1  (Figure  4.11) 
depicts  an  A-37  at  the  center  symbolizing  the  target  aircraft  for  which  the  ISHMS  is 
being  developed.  The  circle  around  the  A-37  represents  the  system  boundaries  that 
will  be  directly  affected  by  the  development  and  implementation  of  an  ISHMS.  Notice 
that  the  circle  is  divided  into  four  different  areas,  namely:  aircraft  monitoring,  data 
management,  aircraft  operations,  and  aircraft  maintenance.  The  first  two  areas  at 
the  top  represent  ISHMS  design  characteristics  and  their  interaction  is  shown  with 
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a  lightning.  The  remaining  two  areas,  shown  at  the  bottom,  represent  systems  that 
would  have  to  evolve  and  adapt  to  the  new  capabilities  provided  by  the  ISHMS.  All 
four  areas  will  be  thoroughly  explained  in  subsequent  paragraphs.  Finally,  the  area 
outside  the  circle  is  labeled  external  systems  and  symbolizes  supporting  systems  that 
may  interact  with  the  ISHMS,  but  will  not  be  affected  by  the  ISHMS.  An  example 
would  be  GPS  satellites  providing  GPS  time  for  ISHMS  data  time-stamping  or  a  com¬ 
munications  network  relaying  aircraft  health  status  to  a  ground  monitoring  station. 
The  satellite  and  radar  systems  shown  in  the  archi-toon  were  drawn  only  for  artistic 
purposes  and  by  no  means  represent  a  pre-dehned  ISHMS  concept. 


Figure  4.11:  OV-1  Architecture 


4-6. 2. 2  OV-5:  Operational  Activity  Diagram.  The  next  architecture 

is  the  OV-5,  also  known  as  the  operational  activity  model  or  IDEFO.  An  OV-5  can 
also  be  presented  as  a  node-tree  diagram.  The  main  difference  between  the  two 
formats  is  the  level  of  detail  in  the  information  presented.  A  node  tree  only  presents 
the  functional  decomposition  whereas  the  operational  activity  diagram  shows  the 


127 


decomposition  as  well  as  the  inputs,  controls,  outputs,  and  mechanisms  (ICOM)  for 
each  of  the  functions.  Both  OV-5  formats  will  be  shown  for  the  benefit  of  the  readers. 
The  node  tree  diagram  (Figure  4.12)  can  be  thought  of  as  a  roadmap  of  the  1DEF0 
diagrams. 

The  thesis  team  started  the  OV-5  development  by  first  defining  the  main  purpose 
of  the  architecture,  which  is  to  provide  a  process  that  would  help  identify  the  ISHMS 
requirements.  As  such,  this  activity  became  the  context  diagram  and  is  shown  in 
figure  4.13.  In  other  words,  by  the  time  the  OV-5  is  fully  explained,  the  reader  should 
have  a  clear  understanding  of  the  activities  the  thesis  team  recommend  be  performed 
when  trying  to  identify  design  requirements  for  the  development  of  an  ISHMS. 

At  this  point  is  worth  mentioning  that  all  OV-5  diagrams  follow  Popkin  rules 
which  include  not  having  more  than  four  ICOM  arrows  on  any  one  side  of  a  function 
box  nor  having  more  than  six  function  boxes  in  any  one  diagram  page.  The  purpose 
of  these  rules  is  to  avoid  clutter  and  confusion  in  the  architectures.  Also,  the  reader 
will  notice  some  of  the  ICOM  arrows  contain  parentheses.  These  parentheses  denote 
what  is  known  as  tunneling,  meaning  that  the  respective  ICOM  is  not  present  in 
its  parent  diagram.  In  most  cases,  tunneling  becomes  necessary  in  order  to  avoid 
clutter  in  the  parent  diagram.  Usually,  tunneling  increases  as  the  number  of  layers  of 
decomposition  increases. 

Next  the  thesis  team  decomposed  the  context  diagram  into  four  major  functions 
or  activities  that  a  hypothetical  ISHMS  should  be  expected  to  perform,  namely:  the 
structural  monitoring  requirements  function,  the  data  requirements  function,  the  op¬ 
erational  requirements  function,  and  the  maintenance  requirements  function  (Figure 
4.14).  The  structural  monitoring  function  refers  to  the  user  requirement  of  detecting 
structural  failure  of  an  aging  aircraft  without  human  intervention.  The  thesis  team 
determined  that  the  only  feasible  way  to  automate  this  process  and  satisfy  this  user 
requirement  was  by  using  sensors  onboard  the  aircraft.  All  decisions  about  the  sensors 
(i.e.,  placement,  quantity,  properties,  sensitivity)  fall  under  the  monitoring  function. 
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Figure  4.12:  Node  Tree 
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Figure  4.13:  AO  Architecture 
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Figure  4.14:  A-0  Architecture 
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Another  major  function  is  the  data  requirements  function,  which  deals  with  decisions 
about  data  acquisition,  handling  and  processing.  Next  is  the  operational  function, 
which  captures  user  preferences  about  the  operational  use  of  the  hypothetical  ISHMS. 
Lastly,  the  maintenance  function  has  to  do  with  decisions  about  sustaining,  validat¬ 
ing,  and  maintaining  the  system.  Initially,  the  thesis  team  thought  that  operations 
and  maintenance  requirements  could  be  lumped  into  one  single  function,  especially 
when  considering  the  CAF  A-37  fleet  of  only  13  aircraft.  However,  the  integration  of 
an  ISHMS  to  a  larger  fleet  of  aircraft  and  a  more  complex  organizational  structure, 
such  as  that  of  the  USAF,  would  certainly  justify  the  separation  of  the  two  functions. 
Thus,  the  thesis  team  decided  to  separate  the  two  functions  so  the  architecture  would 
fit  into  a  larger  number  of  possible  operational  scenarios. 

Next,  the  thesis  team  decomposed  the  monitoring  requirements  one  more  layer 
(Figure  4.15).  The  thesis  team  determined  that  the  best  way  to  implement  an  ISHMS 
would  be  through  the  use  of  a  sensor  network  capable  of  detecting  structural  failures 
in  various  FCLs  of  an  aging  aircraft.  Based  on  this  assumption,  the  monitoring 
requirements  were  decomposed  into  three  main  functions.  First  function  was  to  de¬ 
termine  the  location  of  each  sensor  of  the  ISHMS  sensor  network.  Second  function 
was  to  determine  how  many  sensors  were  needed.  The  last  function  was  to  determine 
requirements  for  the  type  of  sensor  needed  on  each  of  the  sensor  locations. 

The  monitoring  requirements  were  decomposed  one  more  time  (Figure  4.16) 
starting  with  determining  sensor  location  requirements.  Possible  sensor  locations 
were  divided  into  two  general  categories:  fatigue  critical  locations  and  other  critical 
locations.  By  doing  this,  the  thesis  team  purposely  opened  the  door  to  monitor  other 
aircraft  components  that  may  capitalize  on  the  ISHMS  development.  Sensor  loca¬ 
tions  will  most  likely  be  determined  by  compiling  historical  data  on  the  maintenance 
and  inspections  performed  on  the  airframe,  although  some  stakeholders  may  provide 
justification  for  other  specific  locations.  Using  the  A-37  as  an  example,  historical 
data  can  be  found  at  Hill  AFB  through  the  MAPA  Engineering  Analysis  Division, 
by  compiling  the  data  from  flight-line  maintenance  records,  through  interviews  of  pi- 
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Figure  4.15:  A-l  Architecture 
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lots  and  maintainers,  and/or  contacting  the  depot  or  equivalent  services  organization. 
The  list  of  potential  critical  locations  will  depend  on  the  thoroughness  of  the  research 
conducted,  the  quality  of  the  maintenance  practices,  and  the  level  of  aggressiveness  of 
the  flight  profiles  being  flown.  In  addition,  specific  aircraft  design  characteristics  may 
limit  the  ISHMS  options  as  well  as  the  budget  may  impose  a  limit  on  the  amount  of 
locations  being  monitored.  The  overall  goal  of  this  activity  should  be  to  end  with  an 
accurate  list  of  critical  locations  and  prioritize  the  list  in  order  of  importance.  Ob¬ 
viously,  emphasis  should  be  placed  on  those  locations  that  have  a  higher  probability 
of  occurrence  and  a  higher  level  of  risk.  A  risk  management  analysis  of  all  critical 
locations  should  be  appropriate  to  accomplish  this  activity.  The  mechanisms  respon¬ 
sible  of  accomplishing  this  task  are  the  stakeholders  and  any  engineers  hired  to  do 
the  research  job. 

In  addition  to  finding  which  locations  should  be  monitored,  it  is  necessary  to 
find  out  how  many  sensors  are  adequate  to  get  the  job  done  since  it  may  be  necessary 
to  place  more  than  one  sensor  per  critical  location.  This  introduces  the  next  decom¬ 
position  diagram  (Figure  4.17).  The  amount  of  sensors  will  most  likely  be  dependent 
upon  the  desired  SOF,  accuracy,  and  reliability  of  the  ISHMS  in  detecting  failures. 
By  accuracy  of  the  ISHMS  the  thesis  team  refer  to  the  confidence  level  on  detecting 
a  failure.  Users  may  have  an  input  in  this  activity,  but  the  weight  of  the  decision  will 
rely  primarily  upon  engineering  analysis  backed  up  by  established  safety  regulations 
and  policies.  Cost  will  most  likely  be  one  of  the  most  limiting  factors  in  this  decision 
since  there  is  a  direct  proportional  relationship  between  the  amount  of  sensors  and 
the  total  cost  of  the  system. 

The  last  function  within  the  monitoring  requirements  was  the  determination  of 
sensor  properties  requirements.  This  is  a  very  important  function  because  it  deals 
with  tailoring  each  sensor  of  the  network  according  to  the  failure  mode  that  needs  to 
be  detected  and  the  environmental  conditions  (both  internal  and  external)  that  the 
sensor  must  withstand.  Failure  modes  can  be  due  to  a  number  of  conditions  including 
corrosion,  stresses,  torques,  extreme  temperatures,  vibration,  or  any  other  condition 
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Figure  4.16:  A- 11  Architecture 
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that  weakens  a  structural  member  to  the  point  of  catastrophic  failure.  For  example,  if 
a  sensor  is  placed  near  the  wing  root  attachment  on  an  A-37,  then  the  sensor  must  be 
able  to  work  properly  under  extreme  temperatures  and  vibration  of  its  surrounding 
environment  as  a  result  of  the  proximity  to  the  engine. 

The  decomposition  of  the  sensor  properties  function  (Figure  4.18)  start  with 
determining  the  failure  mode  that  needs  to  be  detected,  since  different  failure  modes 
will  most  likely  require  different  sensors.  The  next  step  is  to  identify  the  internal  and 
external  environmental  factors  to  which  the  sensor  will  be  exposed  for  each  of  the  loca¬ 
tions.  An  example  of  an  internal  or  localized  environmental  factor  would  be  a  critical 
location  that  is  submerged  in  hydraulic  fluid,  or  any  other  condition  that  results  from 
the  sensor  being  placed  onboard  the  aircraft.  External  factors  refer  to  the  external 
operational  environment  to  include  weather  conditions.  For  example,  proximity  to 
sea  water  may  promote  corrosion  problems,  or  a  dusty  environment  may  require  a 
sensor  with  additional  protection  from  the  elements,  and  extreme  temperatures  may 
affect  the  electronic  properties  of  the  sensor,  thus  resulting  in  false  readings.  Another 
activity  within  the  sensor  properties  function  is  to  determine  the  technologies  that 
will  be  incorporated  into  the  ISHMS.  As  a  result,  sensor  selection  will  certainly  be 
limited  by  the  monitoring  technologies  available.  Existing  technologies  would  be  more 
readily  available  on  the  market  and  most  likely  be  cheaper  than  emerging  technolo¬ 
gies.  Finally,  after  taking  into  consideration  the  failure  mode,  environmental  factors, 
and  available  technologies,  then  a  sensor  can  be  tailored  and  matched  to  a  specific 
location  with  cost  being  another  limiting  factor.  The  stakeholders  must  realize  that 
there  is  enormous  potential  for  trade-off  opportunities  to  be  considered  when  making 
decisions  about  sensor  selection  and  placement. 

Once  the  sensor  network  is  in  place,  then  the  next  major  ISHMS  function  to 
be  decomposed  is  the  data  requirements  function  (Figure  4.19).  The  thesis  team  di¬ 
vided  data  requirements  into  three  sub  functions:  data  storage  requirements,  data 
processing  requirements,  and  data  analysis  requirements.  Data  storage  requirements 
are  directly  correlated  to  the  quantity  of  sensors  that  compose  the  ISHMS;  therefore, 


137 


Figure  4.18:  A- 13  Architecture 
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Figure  4.19:  A-2  Architecture 
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data  storage  requirements  will  increase  as  the  quantity  of  sensors  increases.  Each 
sensor  outputs  raw  data  that  must  be  stored  and  sorted  for  future  processing.  The 
limiting  factor  in  the  data  storage  requirements  may  come  from  various  sources,  but 
at  least  bandwidth  availability  is  definitely  a  potential  limiting  factor.  Once  the  data 
has  been  properly  and  securely  stored,  then  it  needs  to  be  processed.  Data  process¬ 
ing  requirements  may  include  sorting,  synchronizing,  and  filtering  the  raw  data.  In 
other  words,  each  data  string  must  be  identified  with  information  such  as  the  sen¬ 
sor  it  came  from,  the  time  of  the  measurement,  and  determining  whether  the  data 
string  falls  within  the  range  of  possible  or  acceptable  values.  The  processed  data  must 
then  be  manipulated  and  analyzed.  Data  analysis  could  be  automated,  manual,  or  a 
combination  of  both.  Particular  attention  must  be  given  to  identifying  data  analysis 
requirements  since  these  decisions  will  greatly  influence  the  ISHMS  development  and 
design.  Furthermore,  if  the  ISHMS  must  interact  with  any  legacy  systems,  then  there 
will  be  a  greater  potential  for  unintended  circumstances  such  as  data  compatibility 
issues.  Considering  the  vast  amount  of  possibilities  for  performing  data  analysis,  the 
thesis  team  decided  to  create  several  hypothetical  operational  scenarios.  The  main 
purpose  of  the  operational  scenarios  was  first  to  investigate  the  various  ISHMS  real¬ 
izations  and  second  to  avoid  steering  the  ISHMS  design  in  any  particular  direction. 
For  example,  one  operational  scenario  may  be  that  the  ISHMS  provides  continuous 
real-time  measurements  and  a  dummy-light  or  visual  display  in  the  cockpit  signals  the 
pilot  that  there  is  a  potential  structural  problem.  In  this  scenario,  the  pilot  is  imme¬ 
diately  aware  of  the  problem  and  can  react  according  to  the  emergency  procedures. 
Another  scenario  is  one  where  the  sensor  data  is  up  linked  via  a  communications 
system  (i.e. ,  satellite,  Link-16,  etc.)  and  down  linked  to  a  central  processing  ground 
station.  In  this  scenario  if  a  problem  is  detected,  then  the  control  tower  personnel 
will  be  notified  and  they  will  take  action  to  safely  ground  the  aircraft  by  providing 
pilots  with  emergency  procedures.  Another  possible  operational  scenario  is  one  where 
the  ISHMS  is  passively  collecting  sensor  data  and  at  the  end  of  the  flight  or  mission 
a  data  logger  would  be  responsible  for  downloading  the  ISHMS  from  the  aircraft  and 


140 


into  a  database  for  an  automated  analysis.  In  this  scenario,  any  potential  problems 
will  be  known  and  handled  after  the  fact,  thus  limiting  the  potential  for  immediate 
risk  avoidance.  However,  this  last  scenario  may  be  the  cheapest  and  simplest  option 
to  implement.  Many  other  scenarios  are  possible,  but  it  will  be  up  to  the  stakehold¬ 
ers  and  engineers  to  make  those  trade-off  decisions,  which  will  be  constrained  by  the 
amount  of  money  available. 

The  third  major  functional  decomposition  (Figure  4.20)  deals  with  determin¬ 
ing  ISHMS  operational  requirements.  The  team’s  main  concern  within  this  function 
was  exploring  the  events  unfolding  after  the  ISHMS  data  had  been  analyzed.  This 
involved  determining  potential  information  exchanges  and  responsibilities  among  or 
within  organizations.  This  external  activity  was  included  because  the  decisions  made 
in  this  step  may  influence  the  final  outcome  of  the  ISHMS  design.  Again,  given  the 
wide  range  of  possibilities,  hypothetical  scenarios  were  developed  to  avoid  the  risk 
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Figure  4.20:  A-3  Architecture 
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of  suggesting  a  specific  solution.  A  possible  scenario  is  one  in  which  the  ISHMS  is 
used  to  assess  the  structural  health  of  individual  aging  aircraft  as  a  way  to  shift  from 
preventive  to  condition-based  maintenance.  In  other  words,  instead  of  inspecting  and 
performing  preventive  maintenance  every  number  of  flight  hours,  continuous  struc¬ 
tural  monitoring  may  eliminate  the  need  for  inspections  and  delay  maintenance  for 
when  it  is  really  needed.  In  this  scenario,  the  benefits  of  having  an  ISHMS  can  be 
measured  from  the  potential  for  savings  (i.e.,  cost  avoidance)  on  operations  and  main¬ 
tenance  in  addition  to  the  resulting  increase  in  aircraft  availability.  A  more  complex 
scenario  would  be  an  ISHMS  data  repository  that  analyzes  usage  trends  of  a  fleet  of 
aircraft  and  suggests  the  rotation  of  aircraft  between  different  organizations  to  keep 
the  wear  and  tear  of  the  fleet  even.  For  example,  ISHMS  may  suggest  that  specific 
F-15C  tail  numbers  from  Air  Combat  Command  be  rotated  with  specific  F-15  tail 
numbers  from  Air  Force  Materiel  Command  (AFMC)  in  order  to  even  out  and  main¬ 
tain  an  optimal  safety  and  operational  status  throughout  all  organizations;  assuming 
AFMC  aircraft  flight  profiles  are  less  severe.  Obviously,  the  latter  scenario  would 
require  extensive  strategic  and  tactical  planning  as  well  as  the  buy-in  of  higher  man¬ 
agement  before  being  implemented.  In  addition,  an  ISHMS  may  be  used  to  introduce 
more  efficiency  and  control  in  the  planning  and  scheduling  of  aircraft  maintenance 
activities.  For  example,  data  analysis  may  be  able  to  forecast  the  amount  of  flight 
hours  left  on  an  aircraft  before  it  is  due  for  maintenance.  Maintainers  and  flight  com¬ 
manders  can  then  plan  accordingly  the  flying  schedule.  In  addition,  the  ISHMS  may 
be  able  to  point  out  those  locations  that  will  require  maintenance  in  the  near  future 
so  that  all  maintenance  can  be  performed  at  once;  without  the  need  for  inspections 
that  usually  involve  lengthy  invasive  procedures. 

Finally,  the  last  functional  decomposition  (Figure  4.21)  was  determining  the 
ISHMS  maintenance  requirements.  This  includes  installing,  repairing,  validating, 
calibrating,  and  other  maintenance  of  the  ISHMS.  Depending  on  the  complexity  and 
technology  of  the  ISHMS,  some  of  these  services  may  be  performed  on-site  or  they  may 
require  mobilizing  the  aircraft  to  specialized  facilities.  The  level  of  maintenance  of 
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the  ISHMS  will  mostly  depend  on  the  level  of  reliance  on  the  ISHMS.  If  for  example, 
the  time  interval  between  inspections  is  to  be  increased  as  a  result  of  having  an 
ISHMS  then  this  would  require  a  more  robust  system  and  probably  a  stricter  ISHMS 
maintenance  schedule.  One  way  to  increase  the  robustness  or  reliability  of  a  system 
is  by  adding  redundancy,  which  in  turn  demands  a  higher  cost  and  complexity. 


Figure  4.21:  A-4  Architecture 

4 -6. 2. 3  OV-2:  Node  Connectivity  Diagram.  Next  architecture  devel¬ 

oped  was  the  OV-2  (Figure  4.22),  also  known  as  the  Operational  Node  Connectivity 
Description.  This  diagram  depicts  the  overall  system  nodes  and  the  information  ex¬ 
changes  between  the  nodes.  The  OV-2  shows  five  operational  nodes,  namely:  the 
monitoring  node,  the  data  management  node,  aircraft  operations  node,  aircraft  main¬ 
tenance  node,  and  the  external  systems  node. 
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Figure  4.22:  OV-2  Architecture 
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Notice  the  similarity  between  the  ISHMS  operational  functions  in  the  OV-5  and 
the  operational  nodes  in  the  OV-2.  Also  shown  in  the  OV-2  are  the  information  need¬ 
lines  connecting  the  nodes;  six  needlines  were  identified.  The  first  needline  connects 
the  monitoring  and  data  management  nodes.  This  represents  the  raw  sensor  data 
going  into  the  data  acquisition  unit.  Data  processing  and  analysis  are  assumed  to 
occur  in  the  data  management  node,  which  could  be  a  system  or  organization.  The 
external  systems  node  is  feeding  the  data  management  node  with  a  data  processing 
needline.  This  particular  needline  may  represent  external  data  used  for  time-stamping 
of  the  raw  sensor  data  (e.g.,  GPS  time)  or  it  could  represent  data  logger  feeding  into 
an  ISHMS  repository.  The  actual  meaning  will  depend  on  the  final  ISHMS  solution. 
Then  the  data  management  node  is  responsible  of  alerting  the  aircraft  operations  node 
of  potential  structural  failures.  The  aircraft  operations  node  could  be  either  the  pilot 
flying  the  aircraft,  control  tower,  an  ISHMS  data  analyst,  or  a  combination  of  these; 
it  will  all  depend  on  the  final  ISHM  design.  In  addition,  the  data  management  node 
will  pinpoint  the  aircraft  maintenance  node  the  specific  locations  that  require  main¬ 
tenance.  In  some  instances,  aircraft  repairs  and/or  inspections  may  require  external 
involvement  (e.g.,  aircraft  depot  or  contracted  experts)  and  for  this  reason  there  is  a 
needline  shown  going  from  the  external  systems  into  the  aircraft  maintenance  node. 

4-6. 2. 4  OV-3:  Operational  Information  Exchange  Matrix.  Then  the 

thesis  team  developed  the  OV-3,  also  known  as  the  Operational  Information  Exchange 
Matrix.  This  architecture  product  is  textual  and  provides  information  about  the  OV- 
2  needlines.  Basically,  this  matrix  shows  the  same  information  that  was  described  in 
the  previous  paragraph.  Thus,  the  OV-3  is  shown  in  Figure  4.23  and  the  reader  is 
referred  to  the  previous  paragraph  for  its  interpretation. 

4 -6. 2. 5  Remarks.  So  far,  the  thesis  team  have  shown  the  development 
of  the  AV-1,  AV-2,  OV-1,  OV-2,  OV-3,  and  OV-5.  According  to  the  DoDAF  require¬ 
ments  for  an  integrated  architecture,  the  thesis  team  would  still  be  missing  the  SV-1 
and  TV-1.  In  addition,  the  DoDAF  suggests  the  SV-5  matrix  for  an  acquisition  de- 
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Needline  Identifier  | 

Needline  Name 

Content 

Scope 

Accuracy 

Language 

Sending  Op  Node 

Name 

Receiving  Op  Node 

Name 

Mission/Scenario 

Transaction  Type 

Triggering  Event 

Criticality 

1 
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Data 

Raw 

Sensor 

Data 

Hypothetical 

ISHMS 

seconds 

Digital 

Monitoring 

Data 

Management 

Structural 

Health 

Assessment 

Network 

Active 

Continuous 

Collection 

High 

2 

Data 

Processing 

Processed 

Data 

Hypothetical 

ISHMS 

mili-seconds 

Digital 

External 

Systems 

Data 

Management 

Structural 

Health 

Assessment 

Collaborate 

Active 
Continuous 
Data  Log 

High 

3 

Alert  Signal 

Alert 

Signal 

Hypothetical 

ISHMS 

mili-seconds 

Visual 

Display 

Data 

Management 

Aircraft 

Operations 

Catastrophic 

Failure 

Avoidance 

Direct 

Structural 

Failure 

High 

4 

Emergency 

Procedures 

Control 

Tower 

Hypothetical 

ISHMS 

minutes 

English 

External 

Systems 

Aircraft 

Operations 

Catastrophic 

Failure 

Avoidance 

Collaborate 

Airborne 

Emergency 

High 

5 

Critical 

Locations 

Failure 

Locations 

Hypothetical 

ISHMS 

days 

Engineering 

Views 

Data 

Management 

Aircraft 

Maintenance 

Problem 

Areas 

Identification 

Collaborate 

ISHMS 

Failure 

Indication 

High 

6 

Repairs 
&  Inspections 

Maintenance 

Procedures 

Hypothetical 

ISHMS 

days 

English 

External 

Systems 

Aircraft 

Maintenance 

Problem 

Solution 

Collaborate 

Tasking 

Order 

High 

Figure  4.23:  OV-3  Architecture 


velopment.  However,  all  these  remaining  products  require  knowledge  on  the  physical 
systems  and  interfaces  that  make  up  the  ISHMS,  all  of  which  is  out  of  the  scope  of  this 
thesis  study.  As  such,  the  thesis  team  decided  to  limit  the  architecture  development 
to  the  products  that  have  been  developed  so  far.  As  a  final  note  to  the  reader,  even 
though  this  may  seem  like  a  straight-forward  architecture,  its  development  was  far 
from  straight-forward.  There  were  several  false  starts  and  iterations  before  arriving 
to  its  current  state.  Ensuring  that  the  OV-5  was  balance  was  not  an  easy  task,  even 
when  Popkin  pinpointed  the  errors.  Furthermore,  some  necessary  activities,  such 
as  the  training  activity,  were  intentionally  omitted  because  they  would  require  more 
knowledge  on  the  physical  characteristics  of  the  system  in  order  for  the  architecture  to 
provide  insightful  information.  Nevertheless,  the  requirements  identification  process 
streamlined  in  this  architecture  should  be  able  to  guide  the  reader  to  ask  the  right 
questions  to  the  proper  stakeholders.  Eventually,  the  identification  of  ISHMS  design 
requirements  would  reduce  the  number  of  possible  ISHMS  realizations  and  lead  into 
trade-off  studies  for  ultimate  determination  of  the  final  ISHM  solution. 
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The  results  of  the  structural  model  are  presented  in  the  following  section.  The 
benefit  analysis  is  composed  of  a  structural  model  that  feeds  into  both  a  baseline  300 
hour  simulation  and  ISHMS  modified  simulation. 

Structural  Model  Scope  of  Work 

The  comparison  of  the  baseline  Cessna  A-37  300  hour  inspection  schedule  versus 
the  extended  inspection  schedule  with  an  ISHMS  installed  required  the  development  of 
a  structural  model  to  predict  the  stress  occurring  at  a  FCL.  The  aircraft  usage  profile 
(flight  spectrum)  was  established  along  with  a  typical  weapons  loadout  to  estimate 
crack  growth  and  determine  aircraft  service  life  (how  many  cycles  the  wings  can  be 
loaded  until  fracture).  Countries  can  save  maintenance  resources  by  maximizing  the 
inspection  interval  of  the  aircraft  currently  in  their  inventory  while  maintaining  SOF 
at  the  same  level  as  the  current  300  hour  inspection  interval.  Flight  profiles  and 
the  amount  of  weapons  carried  cannot  be  modified  without  negatively  affecting  the 
mission,  so  the  stress  model  at  the  FCL  was  determined  with  the  pylon  weapon  loads 
as  the  design  variables.  Each  weapon  pylon  location  has  maximum  load  ratings, 
but  this  structural  model  determined  the  stress  applied  at  a  FCL  from  the  applied 
weapons  load  and  flight  profile. 

This  analysis  modeled  the  stress  at  the  front  spar  wing  attach  fitting  of  a  sub¬ 
sonic  Cessna  A-37  Dragonfly  using: 

1.  I-DEAS®  FE  Analysis  model 

2.  JUMP®  response  surface  metamodel 

3.  Excel®  flight  spectrum  stepped  approximation 

The  purpose  of  this  structural  modeling  was  to  estimate  crack  growth  propagation  at 
the  front  spar  wing  attach  fitting  FCL  to  facilitate  an  ISHMS  benefit  analysis. 

The  stress  intensity  range,  AK,  was  based  on  the  stress  amplitude,  Act,  the 
boundary  condition  factor,  f(g),  and  the  crack  length,  a.  The  stress  amplitude,  A cr, 
was  the  difference  between  the  maximum  and  minimum  stress  (Figure  3.15). 
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Minimum  stress,  crmin,  was  assumed  as  the  unloaded  wing  configuration  i.e., 
o~min= 0.  The  aircraft  flight  load  was  assumed  as  SLUF.  The  goal  was  to  predict 
the  maximum  stress,  amax,  from  the  SLUF  and  weapon  loading  configurations.  The 
difference  in  the  two  stresses  was  the  stress  amplitude  used  to  calculate  the  crack 
growth  rate  and  cycles  until  failure,  Nf.  The  maximum  stress,  crmax,  on  the  wing  was 
determined  by  the  weight/location  of  the  weapons  and  the  lift  load. 

4-8  Design  Goals 

The  design  variables  were  defined  as  the  amount  of  weapon  and  fuel  force  (lbf) 
loaded  at  each  of  the  four  pylon  locations  and  wing  tip  (xi,  x2,  x3,  x4,  &  x5)  (Figure 
3.16).  Note:  the  location  of  the  weapon  pylons  were  fixed  and  could  not  be  changed, 
only  the  amount  of  loading  at  each  pylon  location  was  changed. 

The  cost  function  was  the  aircraft  stress  (psi)  at  the  wing  root  spar  connection 
to  the  front  spar  carry-through  frame  (wing  attach  fitting)  element  2815  (Figure  3.17). 
Typical  Vietnam  era  weapon  and  fuel  load-out  was  2501  lbs. 

4-9  Problem  Formulation 

Once  a  typical  A-37  weapon  load  was  determined  the  development  of  the  cost 
function  was  broken  down  into  six  stages  and  four  parts: 

1.  The  first  stage  consisted  of  researching  the  Cessna  A-37  Dragonfly  to  gain  an 
understanding  of  the  structure  and  forces  at  work. 

2.  The  second  stage  was  making  engineering  assumptions  to  simplify  the  complex 
A-37  system  into  a  structural  simulation  model. 

3.  The  third  stage  was  distilling  the  simulation  model  down  into  a  response  surface 
regression  metamodel  to  estimate  the  stress  experienced  at  the  wing  attach 
fitting. 

4.  The  fourth  stage  created  a  stepped  approximation  of  a  fighter  flight  spectrum 
to  determine  mission  effects  on  the  stress  at  the  wing  attach  fitting. 
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5.  The  fifth  stage  was  feeding  the  stress  amplitude  per  100  cycles  per  flight  hour 
into  the  MATLAB®  crack  growth  model  to  estimate  crack  growth  at  the  FCL 
over  time. 

6.  The  sixth  stage  was  using  the  crack  growth  model  to  conduct  a  benefit  analysis 
(Figure  3.7). 

4-9.1  Four  Parts  of  Structural  Model.  The  four  parts  to  successfully  execute 
the  structural  model  were: 

1.  Constructed  a  structural  simulation  model  of  the  Cessna  A-37  Dragonfly 

•  Created  a  simulation  model  of  the  wing  using  FE  analysis 

•  Used  adaptive  meshing  to  decrease  element  size  until  max  stress  converged 

2.  Constructed  a  CCD  for  the  response  surface 

•  Generated  orthogonal  fractional  factorial  design  to  minimize  confounding 

•  Determined  design  factor  input  ranges 

3.  Executed  each  of  the  I-DEAS®  FE  simulation  runs 

•  Executed  required  simulations  from  the  fractional  factorial  design 

•  Validated  the  simulation  model  results  using  hand  calculations 

4.  Created  a  response  surface  regression  metamodel  of  the  FE  simulation  model 

•  Conducted  sensitivity  analysis  to  determine  loading  trends  on  stress 

•  Estimated  stress  at  wing  attach  fitting  using  typical  Vietnam  weapon  load- 
out 

5.  Constructed  stepped  approximation  of  fighter  flight  spectrum 

•  Simplified  flight  spectrum  for  crack  growth  model 

•  Estimated  mission  effect  on  wing  attach  fitting  stress  per  flight  hour  cycle 
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4-10  Solution  Approach 


4-10.1  Modeling  Issues  and  Simplifying  Assumptions.  This  analysis  modeled 
the  right  wing  of  the  Cessna  A-37  Dragonfly  (i.e.  half-wing  model)  (Figure  4.24) 
and  consisted  of  a  linear  static  maximum  stress  analysis.  The  flight  spectrum  was 
truncated  into  a  stepped  approximation  and  distilled  into  a  weighted  average  effect 
on  the  wing  attach  fitting  stress  per  flight  hour  cycle. 


Figure  4.24:  A-37  Right  Wing:  Half-wing  Model 


The  structural  components  modeled  consisted  of:  two  spars,  the  wing  root  and 
tip  ribs,  and  the  aircraft  skin  (Figure  4.25).  The  spars  were  modeled  without  spar  caps 
and  the  stringers  and  landing  gear  were  ignored  for  simplicity.  The  airfoil  geometry 
was  a  (NACA)  2418  with  a  chord  length  of  67  in  at  the  wing  root  and  52.8  in  at 
the  wing  tip.  The  span  of  the  wing  was  158  in  with  a  3°  dihedral  and  a  3°  counter 
clockwise  twist  [44]. 

The  spars,  skin,  and  ribs  were  modeled  with  7075-T6  aluminum  FE  shell  meshes 
of  thickness  (1  in,  0.25  in,  and  1  in  respectively)  (Figure  4.26).  These  material  and 
thickness  selections  where  accurate  for  the  spars  and  ribs,  but  an  assumption  for  the 
wing  skin. 

The  interior  ribs  were  only  used  as  weapon  pylon  reference  points  to  attach 
weapon  point  loads.  Weapon  pylon  locations  consisted  of  the  five  rib  locations  farthest 
from  the  fuselage  (to  include  the  wing  tip)  (Figure  3.16). 
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Figure  4.25:  A-37  Right  Wing 

4-10.2  Loading  Conditions.  The  loading  conditions  consisted  of  distributed 
and  point  loads  (Figure  4.27). 

The  point  weapon  loads  were  divided  between  the  front  and  rear  spars  at  each 
of  the  five  rib  locations  nearest  the  wing  tip.  The  total  force  (SLUF  assumption)  of 
each  weapon  load  (from  the  wing  root  outward)  was:  870  lb,  870  lb,  600  lb,  500  lb, 
and  817  lb.  The  lift  load  pressure  distribution  surface  along  the  chord  from  leading 
edge  to  trailing  edge  was  calculated  using  DesignFoil®,  a  subsonic  simulation  program 
utilizing  NACA  airfoil  and  aircraft  performance  data  (Figure  4.28).  Elliptical  equa¬ 
tions  for  the  chord  pressure  distribution  were  solved  via  Mathematica®  and  manually 
iterated  until  they  approximated  the  DesignFOIL®  data  surface. 

The  lift  load  pressure  distribution  surface  along  the  span  from  wing  tip  to  wing 
root  was  approximated  with  normalized  elliptical  equations.  The  span  elliptical  pres¬ 
sure  distribution  equations  were  also  solved  in  Mathematica®  (Figure  4.29). 

The  chord  distributed  pressure  surface  and  span  distributed  pressure  surface 
were  multiplied  together  to  create  a  single  pressure  surface  that  would  describe  the 
distributed  pressure  surface  on  the  wing  (Equation  4.1). 
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Density 

2.81  g/cc 

0.102  lb/in3 

Mechanical  Properties 

Hardness,  Brinell 

150 

150 

Hardness,  Knoop 

191 

191 

Hardness,  Rockwell  A 

53.5 

53.5 

Hardness,  Rockwell  B 

87 

87 

Hardness,  Vickers 

175 

175 

Ultimate  Tensile  Strength 

572  MPa 

83000  psi 

Tensile  Yield  Strength 

503  MPa 

73000  psi 

Elongation  at  Break 

11  % 

11  % 

Elongation  at  Break 

11  % 

11  % 

Modulus  of  Elasticity 

71.7  GPa 

10400  ksi 

Poisson's  Ratio 

0.33 

0  33 

Fatigue  Strength 

159  MPa 

23000  psi 

Fracture  Toughness 

20  MPa-mVi 

18.2  ksi-in>2 

Fracture  Toughness 

25  MPa-mYz 

22.8  ksi-inVz 

Fracture  Toughness 

29  MPa-nY/z 

26.4  ksi-in14 

Machinability 

70  % 

70  % 

Shear  Modulus 

26.9  GPa 

3900  ksi 

Shear  Strength 

331  MPa 

48000  psi 

Figure  4.26:  7075-T6  Aluminum  Properties  [9] 
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Figure  4.27:  Cantilever  Beam  Loading  Conditions  [19] 
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Figure  4.28:  NACA  2418  Chord  Lift  Pressure  Distribution  [44] 


L(z)  ■  L(x)  =  0.00805848  ■ 


1  -  Z2 
1582 


(-0.15328  +  0.030656)  X 
16.31 


■0.15328J 


(4.1) 


This  single  distributed  pressure  surface  equation  was  applied  over  the  wing  box 
in  conjunction  with  the  SLUF  lift  pressure  load  of  0.656  psi  (i.e.  6211  lbs  of  aircraft 
empty  weight  divided  by  9464.2  in2  wing  box  surface  area)  to  simulate  the  lift  loading 
on  the  A-37  wing  in  flight  (Figure  4.30). 


4-10.3  Constraints  (Boundary  Conditions). 

1.  The  A-37  half- wing  simulation  model  was  constrained  as  a  cantilever  beam  (i.e. 
Fixed-Free)  with  all  displacements  and  rotations  at  the  wing  root  set  to  zero 
(Figure  4.31). 

2.  The  element  size  reduces  the  accuracy  of  the  max  stress.  The  original  coarse  FE 
mesh  was  iterated  (twice)  until  the  max  stress  approached  a  constant  maximum 
stress  value  (Figure  4.32). 

3.  Idealized:  All  loading,  material  constants,  and  geometry  is  exact 
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Clear [L,  a,  z] 

w„158  MO  -  ifi*)”  5))* 

Solve[L  ==  1,  a] 

124.093a 

{{a— >  0.00805848}} 

Clear[M,  P,  Q,  eqns,  b,  c,  x] 

M=((-(b+c)*x)/16.31)+  b 

P=/o16-31  Mdx 
Q  =  f0W  31(x  *  M)dx 
eqns  =  {P  ==1,  Q  ==  16.31/4} 

Solve  [eqns,  {b,c}] 

b  +  0.0613121  (-b-c)  x 
8.155  b  -  8.155  c 
44.336  b  -  88.672  c 

(8.155  b  -  8.155  c  ==  1,  44.336  b  -  88.672  c  ==  4.0775} 
{{b— >  0.15328,  c  -»•  0.030656}} 

Figure  4.29:  Elliptical  Pressure  Distribution  Calculations 
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Figure  4.30:  A-37  Right  Wing:  Typical  Deformed  Geometry 


Figure  4.31:  A-37  Finite  Element  Mesh  with  Cantilever  Boundary  Conditions 
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Figure  4.32:  Effect  of  Refining  A-37  Finite  Element  Mesh  Size  with  Adaptive  Mesh¬ 
ing 


4-10.4  Performance  Measure  (Criteria  for  Successful  Structural  Model  De¬ 
sign).  Maximum  von  Mises  stress  at  element  2815,  crmax,  was  the  performance 
measure  and  criteria  for  successful  structural  model  design: 


&max  &lift  4”  &weaponxl  A  @ weaponX2  A  &weaponX3  A  &weaponX£  A  &weaponx g  (A  2  ) 

4-10.5  Constructed  CCD  for  the  Response  Surface.  There  was  a  design 
factor  (x!,  x2,  x3,  x4,  &  x5)  for  each  of  the  four  wing  pylon  loading  locations  and  the 
wing  tip  tank  location.  These  five  factors  had  three  levels,  1  when  the  pylon  was 
loaded,  -1  when  the  pylon  was  left  empty,  and  0  at  the  midpoint  (Figure  4.33). 

Complete  enumeration  of  the  solution  space  required  35  =  243  FE  model  simu¬ 
lation  runs  to  be  executed.  An  orthogonal  1/4  fractional  factorial  design  was  chosen  to 
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Figure  4.33:  Design  Factor  Levels  for  the  Central  Composite  Design 

reduce  the  number  of  required  simulation  model  runs  to  27  (with  2  midpoints  making 
28)  while  not  introducing  confounding  between  main  effects  (Table  4.1). 

The  design  factor  range  was  the  maximum  allowable  pylon  load  if  the  fractional 
factorial  design  was  1,  0  if  the  fractional  factorial  design  was  -1,  and  half  the  maximum 
pylon  load  for  the  fractional  factorial  design  midpoint  0. 

The  A-37  FE  simulation  model  was  executed  for  each  of  the  28  fractional  fac¬ 
torial  design  runs  and  the  maximum  stress  results  at  element  2815  were  tabulated. 
Due  to  the  geometry  of  the  FE  model  the  highest  stress  location  was  consistently  on 
the  bottom  edge  of  the  front  spar  at  the  wing  root  (Figure  4.34). 

The  FE  simulation  model  von  Mises  stress  (psi)  results  were  tabulated  for  ele¬ 
ment  2815  (Table  4.2). 

4-10.6  Simulation  Model  Validation  with  Hand  Calculations.  Validation  of 
the  FE  model  required  the  A-37  wing  to  be  simplified  as  a  hollow  cantilever  rectan¬ 
gular  box  beam  (with  the  two  spars  added  back  into  the  second  moment  of  inertia). 
The  beam  was  158  in  long,  with  a  52.8  in  width,  height  of  5.82  in,  and  skin  thickness 
of  0.25  in.  The  weapon  location  point  loads  were  kept  at  the  original  magnitudes  but 
the  distributed  lift  load  magnitude  of  6211  lb  was  reduced  to  1/gth  to  simulate  the 
effects  of  the  two  elliptical  distributions  on  the  loading  and  moments.  The  smaller 
outer  wing  tip  dimensions  were  projected  down  the  length  of  the  beam  to  create  a 
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Table  4.1:  Central  Composite  Design 


Simulation  Number 

CCD  Pattern 

XI 

X2 

X3 

X4 

X5 

i 

— 

-1 

-1 

-1 

-1 

-1 

2 

- h  + 

-1 

-1 

-1 

1 

1 

3 

-  H - h 

-1 

-1 

1 

-1 

1 

4 

-  +  +  - 

-1 

-1 

1 

1 

-1 

5 

-  + - h 

-1 

1 

-1 

-1 

1 

6 

-1 

1 

-1 

1 

-1 

7 

-  +  +  - 

-1 

1 

1 

-1 

-1 

8 

-  +  +  +  + 

-1 

1 

1 

1 

1 

9 

H - h 

1 

-1 

-1 

-1 

1 

10 

H - h  - 

1 

-1 

-1 

1 

-1 

11 

H - 1 - 

1 

-1 

1 

-1 

-1 

12 

+  -  +  +  + 

1 

-1 

1 

1 

1 

13 

+  +  - 

1 

1 

-1 

-1 

-1 

14 

+  +  -  +  + 

1 

1 

-1 

1 

1 

15 

+  +  H - b 

1 

1 

1 

-1 

1 

16 

+  +  +  +  - 

1 

1 

1 

1 

-1 

17 

a  0  0  0  0 

-1 

0 

0 

0 

0 

18 

A  0  0  0  0 

1 

0 

0 

0 

0 

19 

0  a  0  0  0 

0 

-1 

0 

0 

0 

20 

0  A  0  0  0 

0 

1 

0 

0 

0 

21 

0  0  a  0  0 

0 

0 

-1 

0 

0 

22 

0  0  A  0  0 

0 

0 

1 

0 

0 

23 

0  0  0  a  0 

0 

0 

0 

-1 

0 

24 

0  0  0  A  0 

0 

0 

0 

1 

0 

25 

0  0  0  0  a 

0 

0 

0 

0 

-1 

26 

0  0  0  0  A 

0 

0 

0 

0 

1 

27 

0  0  0  0  0 

0 

0 

0 

0 

0 

28 

0  0  0  0  0 

0 

0 

0 

0 

0 

Figure  4.34:  Max  Stress  on  Bottom  Edge  of  Front  Spar 
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Table  4.2:  Central  Composite  Design  Results 


Simulation  Number 

CCD  Pattern 

XI 

X2 

X3 

X4 

X5 

Y 

i 

— 

-1 

-1 

-1 

-1 

-1 

2907 

2 

-  +  + 

-1 

-1 

-1 

1 

1 

4569 

3 

-  H - b 

-1 

-1 

1 

-1 

1 

3679 

4 

-  +  +  - 

-1 

-1 

1 

1 

-1 

1805 

5 

-  + - b 

-1 

1 

-1 

-1 

1 

2765 

6 

-1 

1 

-1 

1 

-1 

1993 

7 

-  +  +  - 

-1 

1 

1 

-1 

-1 

2018 

8 

-  +  +  +  + 

-1 

1 

1 

1 

1 

4569 

9 

H - b 

1 

-1 

-1 

-1 

1 

2515 

10 

H - b  - 

1 

-1 

-1 

1 

-1 

1773 

11 

H - b  - 

1 

-1 

1 

-1 

-1 

3459 

12 

+  -  +  +  + 

1 

-1 

1 

1 

1 

4348 

13 

+  H - 

1 

1 

-1 

-1 

-1 

1986 

14 

+  +  -  +  + 

1 

1 

-1 

1 

1 

4536 

15 

+  +  +  -  + 

1 

1 

1 

-1 

1 

4561 

16 

-b  H — b  H — 

1 

1 

1 

1 

-1 

3789 

17 

a  0  0  0  0 

-1 

0 

0 

0 

0 

2285 

18 

A  0  0  0  0 

1 

0 

0 

0 

0 

3167 

19 

0  a  0  0  0 

0 

-1 

0 

0 

0 

2175 

20 

0  A  0  0  0 

0 

1 

0 

0 

0 

3277 

21 

0  0  a  0  0 

0 

0 

-1 

0 

0 

2269 

22 

0  0  A  0  0 

0 

0 

1 

0 

0 

3183 

23 

0  0  0  a  0 

0 

0 

0 

-1 

0 

2281 

24 

0  0  0  A  0 

0 

0 

0 

1 

0 

3171 

25 

0  0  0  0  a 

0 

0 

0 

0 

-1 

1895 

26 

0  0  0  0  A 

0 

0 

0 

0 

1 

3557 

27 

0  0  0  0  0 

0 

0 

0 

0 

0 

2726 

28 

0  0  0  0  0 

0 

0 

0 

0 

0 

2726 
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smaller  simplified  wing  that  sets  a  maximum  possible  stress  that  cannot  be  exceeded 
with  a  valid  model  (Figure  4.35). 

It  was  a  good  sign  that  the  maximum  stress  achieved  in  the  fully  loaded  simu¬ 
lation  model  did  not  exceed  the  maximum  theoretical  stress.  Additionally,  the  maxi¬ 
mum  stress  achieved  in  the  simulation  model  was  within  a  power  of  10  of  the  maximum 
theoretical  stress  so  there  was  confidence  that  the  FE  simulation  model  was  valid. 

4-10.7  Response  Surface  Regression  Metamodel. 

•  The  original  A-37  simulation  model  boundaries  were  identified. 

•  The  weapon  pylon  factors  (x4,  x2,  x3,  x4,  &  x5)  contributing  to  the  simulation 
model  were  identified  and  the  range  of  the  factors  (0  to  maximum  pylon  load 
rating)  was  established. 

•  CCD  Fractional  factorial  design  was  used  to  cut  down  the  number  of  simulation 
runs.  Each  of  the  5  factors  had  3  levels  (high,  mid,  and  low  value)  so  the 
number  of  simulation  model  runs  required  was  35.  Conducting  243  runs  would 
have  been  time  consuming  so  a  fractional  1  / 4  factorial  design  was  used  to  reduce 
the  number  of  runs  to  28  (27  +  1  additional  midpoint). 

•  The  max  von  Mises  stress  FE  simulation  model  was  solved  in  I-DEAS®  for  the 
CCD  factor  configurations. 

•  The  form  of  the  A-37  response  surface  regression  model  was  established  as  a 
quadratic  regression  to  include  main  effects,  quadratic  terms,  and  two  factor 
interactions  (Equation  4.3  [64]). 


k 


k 


(4.3) 


h= 1 


h=  1 


k— 1  k 


+  ^2  Phh'XihXw  +  Eu\/i  =  1,  ...,n 

h=  1  h'=h+ 1 
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Figure  4.35: 


Maximum  Stress  Hand  Calculations 
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The  response  surface  regression  metamodel  was  calculated  with  a  R2  value  of 
0.970  indicating  a  metamodel  that  accounts  for  the  vast  majority  of  the  factors  that 
are  influencing  the  max  stress  on  element  2815  of  the  A-37  wing  (Figure  4.36). 


1500  2000  2500  3000  3500  4000  4500  5000 
Y  Predicted  P=0.0016  RSq=0.97 
RMSE=317.15 


Summary  of  Fit 


RSquare  0.969565 

RSquareAdj  0.882609 

Root  Mean  Square  Error  317.1462 

Mean  of  Response  3000.5 

Observations  (or  Sum  Wgts)  28 


Analysis  of  Variance 


Source 

DF 

Sum  of  Squares 

Mean  Square 

F  Ratio 

Model 

20 

22-29”: 

1121489 

11.1500 

Error 

7 

704072 

100582 

Prob  >  F 

C.  Total 

27 

23133847 

n  nni6 

Figure  4.36:  Regression  Metamodel  Results 

Only  parameter  estimates  with  an  F-ratio  greater  than  one  were  included  as 
significant  in  the  response  surface  metamodel  (Table  4.3). 

This  inclusion  of  significant  factors  resulted  in  a  response  surface  model  (Equa¬ 
tion  4.4  [64]).  Even  though  the  quadratic  effects  were  included  in  the  response  surface 
model,  the  F-ratios  show  that  these  second  order  terms  were  not  as  significant  as  the 
first  order  and  two-factor  interactions. 
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Table  4.3:  Regression  Parameter  Estimates 


Term 

Estimate 

F-Ratio 

Probability  >t 

Intercept 

2635.04 

23.86 

<0.0001 

Xl&RS 

198.56 

2.66 

0.0326 

X2&RS 

124.11 

1.66 

0.1408 

X3&RS 

337.11 

4.51 

0.0028 

X4&RS 

241.78 

3.23 

0.0144 

X5&RS 

750.22 

10.04 

<0.0001 

X1*X2 

272.63 

3.44 

0.0109 

X1*X3 

342.5 

4.32 

0.0035 

X2*X3 

135 

1.7 

0.1324 

X1*X4 

20.5 

0.26 

0.8034 

X2*X4 

228.25 

2.88 

0.0237 

X3*X4 

-117.13 

-1.48 

0.1831 

X1*X5 

-117.25 

-1.48 

0.1827 

X2*X5 

90.5 

1.14 

0.2912 

X3*X5 

20.63 

0.26 

0.8022 

X4*X5 

342.63 

4.32 

0.0035 

X1*X1 

113.7 

0.56 

0.5923 

X2*X2 

113.7 

0.56 

0.5923 

X3*X3 

113.7 

0.56 

0.5923 

X4*X4 

113.7 

0.56 

0.5923 

X5*X5 

113.7 

0.56 

0.5923 

a  =  2635  +  199a;  i  +  124x2  +  337x3  +  242x4  +  750x5 

+273xix2  +  343xiX3  +  135x2X3  +  228x2X4  (4.4) 

—  II7X3X4  +  91x2X5  +  343x4X5 

4-10.8  Sensitivity  Analysis.  A  sensitivity  analysis  was  performed  on  the 
response  surface  model  (Equation  4.5).  The  sensitivities  were  calculated  to  determine 
which  factor  had  the  greatest  effect  on  the  stress  induced  in  the  aircraft  wing  attach 
fitting  (element  2815). 
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da 
dx\ 
da 
dx2 
da 
dx3 
da 
dx  4 
da 
dx5 


199  +  273x2  +  343x3  —  117x5 
124  +  273xi  +  135x3  +  228x4  +  91xs 
337  +  343xi  +  135x2  —  117x4 
242  +  228x2  —  117x3  +  343xs 
750  —  117xi  +  91x2  +  343x4 


(4.5) 


Figure  4.37:  Regression  Graphical  Sensitivity 


4-10.9  Fighter  Flight  Spectrum. 

4-10.9.1  Stress  Sequence  Development.  The  sequence  and  intensity  of 
stress  cycles  applied  during  the  life  of  the  aircraft  structure  was  needed  to  estimate 
crack  growth  at  the  wing  attach  fitting  FCL.  This  flight  spectrum  was  usually  recorded 
as  gravitational  loads  per  flight  hour  cycle  (Figure  4.38). 

This  spectrum  was  a  general  fighter  repeated  load  history  due  to  ground  han¬ 
dling,  flight  maneuvers,  gusts,  landing,  store  ejection,  and  other  load  sources.  A-37 
data  was  not  available,  so  this  general  fighter  spectrum  was  used  to  estimate  the 
effect  on  stress  per  flight  hour  cycle  [66].  The  stress  effect  at  any  given  flight  hour 
cycle  was  determined  from  the  spectrum  load  &  stress  relationship  [47] .  Each  aircraft 
mission  type  was  divided  into  segments  which  were  characterized  by  the  type  and 
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11 


•  Positive  G-Load 


Figure  4.38:  General  Fighter  Flight  Spectrum  [66] 


frequency  of  load  sources  (Figure  4.39  [66]).  Multiple  mission  profiles  and  segments 
were  combined  to  determine  the  flight  spectrum.  Specifically,  the  flight  spectrum  was 
constructed  from  aircraft  service  life  data.  Flight  hours,  calendar  years  of  service, 
number  of  missions  flown,  mission  types,  and  number  of  landings  were  included  in 
service  life  data. 

The  flight  maneuver  spectrum  was  determined  by  summing  the  number  of  times 
the  gravitational  load  factors  (g-loads)  were  exceeded  per  flight  hour  cycle.  The  g- 
loads  were  converted  to  percent  of  limit  load  (stress)  (Figure  4.40). 

The  number  of  exceedances  were  truncated  logarithmically.  The  stresses  and 
cycles  were  distributed  among  A-D  decreasing  severity  mission  profiles  (Table  4.4). 
The  stresses  generated  per  flight  hour  cycle  were  combined  in  a  weighted  average  for 
simplification  of  the  crack  growth  model  and  inserted  into  the  benefit  analysis. 
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Stress(%  of  Limit  Load) 


Figure  4.39:  General  Aircraft  Mission  Profile  [66] 


Figure  4.40:  Flight  Stress  Sequence  Stepped  Approximation  [66] 
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Table  4.4:  Stress  and  Cycle  Distribution 


Composite 

1  (Level) 

2  (Exceedances) 

3  (Occurrences) 

1.39 

10 

10 

1.35 

100 

90 

1.15 

1000 

900 

0.9 

10000 

9000 

0.75 

100000 

90000 

0.52 

500000 

400000 

Mission  A 

4  (Occurrences) 

5  (lOx) 

6  (Remain=3-5) 

i 

10 

0 

3 

30 

60 

15 

150 

750 

48 

480 

8520 

300 

3000 

87000 

1900 

19000 

381000 

Mission  B 

7  (Occurrences) 

8  (60x) 

9  (Remain=6-8) 

0 

0 

0 

1 

60 

0 

3 

180 

570 

17 

1020 

7500 

200 

12000 

75000 

1500 

90000 

291000 

Mission  C 

10  (Occurrences) 

11  (570x) 

12  ( Re  main =9-11) 

0 

0 

0 

0 

0 

0 

1 

570 

0 

10 

5700 

1800 

100 

57000 

18000 

400 

228000 

63000 

Mission  D 

13  (Occurrences) 

14  (360x) 

15  (Remain=12-14) 

0 

0 

0 

0 

0 

0 

0 

0 

0 

5 

1800 

0 

50 

18000 

0 

175 

63000 

0 
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4-11  Structural  Model  Discussion  of  Results  and  Summary 

Simulation  and  response  surface  modeling  worked  well.  The  FE  simulation 
correlated  reasonably  well  to  the  hand  calculations.  This  analysis  showed  that  weapon 
loading  correlates  highly  with  wing  attach  fitting  stress.  The  wing  pylon  location  that 
had  the  most  detrimental  effect  on  the  A-37  maximum  wing  stress  is  the  wing  tip  tank 
location  (x5).  The  stress  sensitivities  showed  an  increasing  significance  of  x5  on  the 
induced  stress  of  the  wing  root  front  spar  (element  2815).  Additionally,  the  sensitivity 
analysis  shows  that  the  optimum  loading  configuration  is  to  put  the  heaviest  weapons 
on  the  inner  pylons  first.  Following  these  weapon  pylon  loading  guidelines  resulted 
in  a  maximum  von  Mises  stress,  smax,  of  4790  psi  at  the  wing  attach  fitting  element 
2815.  The  effect  of  applying  the  flight  maneuver  spectrum  was  significant.  The  limit 
load  for  fighter  aircraft  was  7.33g  which  resulted  in  a  weighted  stress  of  20,152  psi  for 
100  cycles  per  flight  hour.  This  was  the  stress  per  cycle  values  input  into  the  Walker 
crack  growth  model  for  the  benefit  analysis. 

The  results  of  the  benefit  analysis  are  presented  in  the  following  section.  The 
benefit  analysis  is  composed  of  a  structural  model  that  feeds  into  both  a  baseline  300 
hour  simulation  and  ISHMS  modified  simulation. 

4-12  Benefit  Analysis 

As  written  in  Chapter  3,  two  MATLAB®  simulations  were  performed  to  gain  a 
rudimentary  analysis  of  the  benefit  of  an  installed  ISHMS  with  respect  to  both  safety 
and  cost.  The  results  of  running  these  two  simulations  while  varying  the  interval 
between  maintenance  inspections  are  presented  in  this  section.  For  reference,  the 
MATLAB®  code  for  the  two  simulations  is  included  in  Appendix  A. 

4-12.1  Baseline  Simulation.  Currently,  CAF  A-37  aircraft  flown  past  the 
design  service  life  are  subject  to  maintenance  inspections  every  300  flight  hours.  The 
baseline  simulation  simulating  the  current  status  quo  was  run  with  inspection  inter¬ 
val  times  of  100,  200,  300,  400,  500,  600  and  700  flight  hours.  The  700  hour  interval 
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Table  4.5:  Baseline  Simulation  Results 


Run 

Inspect  Interval 
(Flight  Hrs) 

Fleet  Failures 
Average 

Fleet  Failures 
Std  Dev 

Failure  Rate 
(per  Min  Fit  Hrs) 

Total 

Failures 

Max  Fleet 
Failures 

Total 

Inspects 

1 

100 

0 

0 

0 

0 

0 

650000 

2 

200 

0.007 

0.0834 

0.1077 

7 

1 

324932 

3 

300 

0.159 

0.3998 

2.4593 

159 

3 

206912 

4 

400 

3.721 

1.5785 

66.6713 

3721 

8 

132434 

5 

500 

3.126 

1.5161 

54.5228 

3126 

8 

113650 

6 

600 

2.767 

1.4632 

47.3156 

2767 

10 

93769 

7 

700 

13.0 

0 

1626 

13000 

13 

90666 

resulted  in  every  aircraft  failing  prior  to  scheduled  inspection.  Any  interval  greater 
than  700  hours  will  also  result  in  every  aircraft  failing  prior  to  inspection,  thus  the 
simulations  were  not  performed  at  intervals  greater  than  700  flight  hours.  The  re¬ 
sults  of  these  seven  runs  are  presented  in  Table  4.5.  These  baseline  runs  helped  to 
characterize  the  baseline  behavior  such  that  it  could  be  compared  with  the  ISHMS 
simulation. 

The  results  showed  that  the  failure  rate  for  the  300  hour  inspection  is  2.4593 
failures  per  million  flight  hours.  This  exceeded  the  current  acceptable  USAF  goal 
of  one  failure  per  million  flight  hours.  The  maximum  fleet  failures  was  three  which 
would  amount  to  23%  of  the  fleet  failing  during  the  5000  flight  hour  life;  this  occurred 
in  0.001%  of  the  trials.  Additionally,  results  showed  that  the  failure  rate  increased 
dramatically  between  300  and  400  hour  inspection  intervals.  At  intervals  greater  than 
400  hours,  the  failure  rate  dropped  some  before  hitting  a  peak  when  all  aircraft  failed 
at  616  hours. 

Since  the  crack  growth  was  deterministically  estimated  and  would  reach  the 
critical  length  at  615  flight  hours,  any  inspection  interval  beyond  615  flight  hours 
for  the  baseline  resulted  in  failures  for  all  aircraft.  The  drop  observed  from  400 
flight  hours  to  615  flight  hours  can  be  attributed  to  the  probability  of  maintenance 
detection.  After  each  maintenance  inspection,  roughly  three  percent  of  the  cracks  do 
not  get  repaired  and  continue  growing.  At  inspection  intervals  greater  than  308  flight 
hours  (half  the  time  until  critical  crack  length),  these  missed  cracks  will  certainly  fail 
before  the  next  inspection.  Since  the  total  time  considered  by  the  model  was  limited 
to  5000  flight  hours,  the  total  number  of  missed  cracks  will  decrease  as  the  inspection 
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interval  increases  from  400  to  616  flight  hours.  For  example,  at  600  flight  hours  there 
will  be  fewer  total  inspections  and  fewer  opportunities  to  miss  cracks  than  at  400  flight 
hours.  This  results  in  fewer  failures  for  the  600  flight  hour  interval  as  compared  to 
the  400  flight  hour  interval.  See  Figure  4.41  for  a  plot  of  failure  rate  versus  inspection 
interval. 


Figure  4.41:  Baseline  Simulation  Failure  Rate  vs.  Inspection  Interval 

Along  with  the  failure  rate,  the  standard  deviation  increased  significantly  be¬ 
tween  300  and  400  hours,  then  decreased  some  until  615  flight  hours  when  all  aircraft 
failed  and  standard  deviation  was  zero.  As  expected,  total  number  of  inspections 
decreased  when  inspection  interval  increased,  due  to  a  combination  of  the  increased 
inspection  interval  and  the  increased  number  of  failures. 

4-12.2  ISHMS  Simulation.  Since  it  would  not  be  desirable  to  decrease  the 
inspection  interval  from  a  cost  standpoint,  the  thesis  team  began  our  simulations  for 
the  ISHMS  at  300  flight  hour  intervals,  the  current  inspection  interval.  The  thesis 
team  then  increased  the  interval  until  every  aircraft  failed  or  until  the  scheduled 
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Table  4.6:  ISHMS  Simulation  Results 


Run 

Inspect  Interval 
(Flight  Hrs) 

Fleet  Failures 
Average 

Fleet  Failures 
Std  Dev 

Failure  Rate 
(per  Min  Fit  Hrs) 

Total 

Failures 

Max  Fleet 
Failures 

Total 

Inspects 

1 

300 

0 

0 

0 

0 

0 

208164 

2 

400 

0.004 

0.0632 

0.0615 

4 

1 

156840 

3 

500 

0.001 

0.0316 

0.0154 

1 

1 

130406 

4 

600 

0.017 

0.1293 

0.2618 

17 

1 

106595 

5 

700 

0.107 

0.325 

1.6522 

107 

2 

103525 

6 

800 

0.103 

0.3201 

1.59 

103 

2 

103555 

7 

900 

0.094 

0.3054 

1.4509 

94 

2 

103576 

8 

1000 

0.106 

0.3207 

1.6373 

106 

2 

103490 

9 

1100 

0.105 

0.3195 

1.6211 

105 

2 

103542 

10 

none 

0.105 

0.3195 

1.6215 

105 

2 

103514 

inspection  interval  was  greater  than  the  remaining  aircraft  life.  The  latter  ending  up 
being  the  case  for  this  simulation;  the  only  inspections  performed  during  run  10  were 
when  the  ISHMS  indicated  a  crack  length  greater  than  90%  of  the  critical  length.  For 
different  runs,  the  thesis  team  increased  the  inspection  interval  by  100  hours  until 
the  failure  rate  exceeded  the  failure  rate  for  the  baseline  simulation  at  300  hours. 
This  never  occurred,  even  with  zero  scheduled  inspections  the  failure  rate  was  1.6215 
failures  per  million  flight  hours.  The  ISHMS  simulation  was  run  with  inspection 
interval  times  of  300,  400,  500,  600,  700,  800,  900,  1000,  1100  and  none.  The  results 
of  these  10  runs  can  be  seen  in  Table  4.6. 

The  failure  rate  increased  dramatically  between  600  and  700  scheduled  inspec¬ 
tion  intervals.  For  inspection  intervals  greater  than  700  flight  hours,  the  failure  rate 
remained  fairly  constant,  even  when  relying  solely  on  the  ISHMS  (i.e.,  zero  sched¬ 
uled  inspections).  The  standard  deviation  of  the  total  failures  also  remained  constant 
during  those  same  simulation  runs.  Never  did  the  maximum  number  of  fleet  failures 
exceed  two.  When  it  did,  it  never  occurred  in  more  than  0.003%  of  the  trials.  The 
total  number  of  inspections  which  included  both  scheduled  and  unscheduled  (i.e., 
tipped  off  by  the  ISHMS)  decreased  from  the  300  to  the  500  flight  hour  interval,  but 
then  remained  relatively  constant  thereafter.  See  Figure  4.42  for  a  plot  of  the  failure 
rate  versus  inspection  interval  with  a  trendline  added. 

A  hypothesis  on  the  reason  for  the  leveling  off  above  500  flight  hours  is  that  the 
crack  grows  to  near  critical  length  at  615  flight  hours  and,  at  that  time  if  the  scheduled 
inspections  do  not  catch  it  then  the  unscheduled  ISHMS  induced  inspections  will, 
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Figure  4.42:  ISHMS  Simulation  Failure  Rate  vs.  Inspection  Interval 

resulting  in  an  inspection  interval  for  both  scheduled  and  unscheduled  inspections  to 
be  relatively  constant  despite  the  scheduled  inspection  interval. 

4-12.3  Discussion  of  Results.  The  simulations  had  many  simplifying  as¬ 
sumptions,  however,  since  many  of  the  assumptions  were  constant  through  the  two 
scenarios,  the  thesis  team  believe  some  basic  conclusions  can  be  made.  Installing  a 
structural  health  monitoring  system  that  provides  real-time  monitoring  and  feedback 
will  most  definitely  improve  safety  for  a  given  scheduled  inspection  interval.  Consid¬ 
ering  the  300  flight  hour  inspection  interval,  the  ISHMS  reduced  the  failure  rate  from 
2.4593  failures  per  million  flight  hours  to  zero  failures.  However,  there  was  a  tradeoff. 
The  number  of  inspections  performed  with  the  ISHMS  was  slightly  greater  than  the 
number  of  inspections  for  the  baseline. 

If  an  ISHMS  was  developed  and  installed,  then,  of  course,  the  CAF  would  take 
advantage  of  this  system  and  subsequently  increase  the  scheduled  inspection  interval. 
Assuming  2.4593  failures  per  million  flight  hours  is  an  acceptable  failure  rate  then 
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the  inspection  interval  with  the  ISHMS  conld  eliminated.  This  might  seem  to  be 
the  course  of  action,  but  eliminating  all  scheduled  inspections  would  then  require 
that  the  fleet  inspections,  roughly  103  per  fleet,  would  all  be  based  on  warnings  from 
the  ISHMS  and  thus  unscheduled.  Having  all  maintenance  inspections  unscheduled 
would  not  be  ideal  from  a  planning  perspective.  Since  the  failure  rate  for  no  scheduled 
inspections  does  not  differ  much  from  the  700  flight  hours  and  greater,  the  optimal 
scheduled  inspection  interval  with  the  ISHMS  would  be  closer  to  700  flight  hours. 
With  a  700  flight  hour  inspection  interval,  most  of  the  103  inspections  per  fleet  would 
be  scheduled  and  just  a  few  would  result  from  an  ISHMS  warning.  This  strikes  a 
balance  between  safety,  cost  and  planning  considerations. 

As  an  example,  if  the  700  flight  hour  inspection  were  selected  to  implement 
with  an  ISHMS  installed,  then  the  failure  rate  would  decrease  from  2.4593  failures 
per  million  flight  hours  to  1.6522  failures  per  million  flight  hours,  a  safety  improvement 
of  32.8%.  Additionally,  total  number  of  inspections  would  decrease  from  207  to  104, 
a  reduction  of  49.8%.  Assuming  a  fixed  cost  for  each  inspection,  then  the  cost  savings 
realized  from  installing  an  ISHMS  system  could  be  calculated  as  the  fixed  cost  of  each 
inspection  times  the  number  of  inspections  saved,  103,  less  the  annualized  life-cycle 
cost  of  an  ISHMS  (includes  development,  procurement,  installation,  maintenance,  and 
disposal).  The  ultimate  decision  on  changing  maintenance  inspections  and  practices 
would  be  set  by  the  stakeholders  to  match  their  preferences  and  goals  for  the  system. 

4-12-4  Sensitivity  Analysis.  The  sensitivity  analysis  reran  the  two  simula¬ 
tions  but  with  the  maintenance  probability  of  inspection  at  98%,  99%,  and  100%. 
For  each  variance  in  maintenance  probability  of  inspection,  the  thesis  team  tried  to 
find  the  ISHMS  inspection  interval  that  most  closely  matched  the  failure  rate  of  the 
baseline  with  a  300  hour  inspection  interval,  but  was  no  worse  than.  For  98%,  the  ap¬ 
propriate  inspection  interval  for  the  ISHMS  would  be  approximately  600  flight  hours. 
This  would  result  in  a  safety  improvement  of  80.8%  and  a  inspection  reduction  of 
49.1%.  For  99%,  the  appropriate  inspection  interval  for  the  ISHMS  would  also  be  600 
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Table  4.7:  Simulation  Results  Summary 


Maintenance 

Prob  of  Detection 

Approx  ISHMS 
Inspection  Interval 

Safety 

Improvement 

Inspection 

Reduction 

97% 

700 

32.8% 

49.8% 

98% 

600 

80.8% 

49.1% 

99% 

600 

50.0% 

49.6% 

100% 

550 

0% 

43.8% 

flight  hours.  This  would  result  in  a  safety  improvement  of  50%  and  a  inspection  re¬ 
duction  of  49.6%.  For  100%,  the  appropriate  inspection  interval  for  the  ISHMS  would 
be  550  flight  hours.  This  would  result  in  no  safety  improvement,  since  no  failures 
occur  in  the  baseline  simulation  with  a  300  hour  inspection  interval.  However,  there 
was  a  inspection  reduction  of  43.8%.  The  results  of  the  sensitivity  analysis,  including 
the  original  estimate  of  97%  for  maintenance  probability  of  detection,  are  included  in 
Table  4.7. 
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V.  Conclusions  and  Recommendations  for  Further  Research 


Figure  5.1:  Chapter  5  Decomposition 


5. 1  Conclusions 

As  introduced  in  Chapter  1  and  further  discussed  in  Chapter  2,  the  USAF  and 
many  other  nations  continue  to  squeeze  as  much  usable  life  out  of  aging  aircraft  as 
possible.  In  order  to  do  so,  the  military  forces  regularly  extend  the  original  aircraft 
service  life  which  often  increases  the  inspection  burden.  To  maintain  flight  safety, 
increased  periodic  inspections  are  required.  Increasing  the  inspections  results  in  more 
aircraft  downtime  and  added  maintenance  costs. 

This  thesis  first  assumed  that  an  ISHMS  for  aging  aircraft  may  help  lower  the 
resulting  inspection  burden  and,  as  such,  reduce  costs  while  maintaining  safety.  To 
begin  to  tackle  the  large  problem  of  developing  an  ISHMS  for  aging  aircraft,  this  thesis 
took  the  first  steps  of  a  generic  SE  process  that  kick  started  the  system  definition. 
Additionally,  the  potential  benefit  with  respect  to  both  cost  and  safety  of  an  ISHMS 
was  quantified  through  the  use  of  mathematical  simulations. 

5.2  SE  Process  Developed 

The  problem  of  structural  health  monitoring  for  aging  aircraft  is  significant  and 
large.  This  thesis  does  not  seek  to  solve  the  entire  problem,  especially  not  for  specific 
aging  aircraft.  This  thesis  scoped  the  problem  by  focusing  on  the  system  definition 
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piece  of  the  SE  process  for  a  generic  aging  aircraft.  The  authors  of  this  thesis  hope 
that  the  generic  process  developed  will  provide  a  starting  point  for  future  researchers 
of  the  ISHMS  problem  or  the  developers  of  an  ISHMS  for  a  specific  aircraft.  When  the 
process  required  a  specific  aircraft  for  development  of  requirements  or  architectures, 
the  CAF  A-37  was  used,  but  most  of  the  process  considered  a  generic  aging  aircraft 
platform.  The  system  definition  process  roughly  followed  the  SE  Vee  Model.  The  two 
steps  of  (1)  defining  the  system  level  design  problem  and  (2)  developing  the  functional 
system  architecture  were  included.  Since  a  generic  platform  was  considered  and  the 
thesis  team  consisted  only  of  system  engineers  and  no  design  engineers,  the  process 
stopped  prior  to  physical  architecture  development  and  system  design.  The  generic  SE 
process  detailed  in  this  thesis  included  a  discussion  of  the  user  perspective,  definition  of 
the  operational  concept,  definition  of  user  and  system  level  requirements,  requirements 
feasibility  analysis  and  development  of  some  integrated  system  architectures. 

5.2. 1  User  Part  of  SE  Process.  In  developing  the  SE  process  the  thesis  team 
had  to  wear  the  hats  of  several  stakeholders.  First,  the  thesis  team  played  the  role 
of  the  user.  The  user  would  initiate  the  development  program  for  an  ISHMS.  This 
thesis  assumed  that  the  user  had  analyzed  the  alternatives  for  decreasing  the  costs 
associated  with  maintaining  aging  aircraft  while  maintaining  flight  safety  and  the  user 
determined  that  an  ISHMS  had  promise  for  solving  the  problem.  When  defining  the 
operational  concept,  the  thesis  team  assumed  the  user  sought  to  use  an  ISHMS  to 
monitor  structural  damage,  specifically  crack  growth,  as  it  occurred.  As  such,  the 
health  of  the  aircraft  structure  could  be  constantly  monitored  and  the  maintenance 
of  the  aircraft  could  be  tailored  to  the  individual  aircraft  based  on  the  results  of  the 
monitoring.  Given  the  assumption  of  an  ISHMS  could  help  solve  the  problem  and 
how  the  user  will  use  an  ISHMS,  the  thesis  team  drafted  the  user  requirements  for 
an  ISHMS.  As  stated,  the  user  requirements  considered  an  generic  aircraft  platform 
except  when  a  specific  platform  was  required.  For  example,  when  the  proper  sampling 
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rate  for  the  ISHMS  was  needed,  the  thesis  team  analyzed  the  A-37  to  determine  what 
sampling  rate  was  necessary  to  capture  the  peak  loads. 

5.2.2  System  Requirements.  After  completing  the  user  piece  role  in  system 
definition,  the  thesis  team  changed  hats  and  played  the  role  of  the  system  engineers. 
The  user  requirements  and  operational  concept  were  then  used  to  write  the  system 
requirements.  The  thesis  team  ensured  requirements  traceability,  that  the  system 
requirements  addressed  each  and  every  user  requirement.  As  the  system  requirements 
were  developed,  the  thesis  team  had  to  go  back  and  clarify  some  user  requirements. 
This  simulated  the  process  of  the  system  engineers  contacted  the  user  for  clarity 
on  requirements  or  more  detail  on  how  the  system  will  be  used.  After  the  system 
requirements  were  finalized,  a  basic  feasibility  check  was  performed  ensuring  that 
each  requirement  could  be  verified  during  system  level  design. 

5.2.3  System  Architectures.  To  further  define  the  ISHMS  and  aid  in  clari¬ 
fying  the  problem,  the  thesis  team  developed  system  architectures.  The  architectures 
developed  followed  the  United  States  DoDAF.  First,  the  AV-1,  and  AV-2  were  created 
that  provided  textual  definitions  and  descriptions  of  the  problem.  The  OV-1  served 
as  a  graphical  depiction  of  the  operational  concept.  The  remaining  architectures  de¬ 
veloped  the  OV-2,  OV-3  and  OV-5  defined  the  functional  processes,  informational 
exchange  and  node  connectivity  specific  to  an  ISHMS.  Further  architectural  products 
would  have  delved  into  the  physical  design  specifics  of  the  ISHMS,  and  thus  this  the¬ 
sis  stopped  the  architecture  development  here.  An  interesting  note,  much  like  when 
developing  the  system  requirements,  development  of  the  system  architectures  often 
identified  gaps  in  the  user  and  system  requirements  which  were  iteratively  corrected 
as  the  architectures  were  created. 

5.2.4  Final  Comments  on  SE  Process.  This  thesis  was  successful  in  devel¬ 
oping  a  generic  SE  process  for  ISHMS  system  definition.  The  SE  process  generated 
a  methodical,  structured  approach  which  allowed  for  the  thesis  team  to  effectively 
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define  an  ISHMS  for  a  non-specific  aging  aircraft.  Th estrawman  process  serves  as  the 
starting  point  for  further  system  developers.  After  the  completion  of  the  SE  process, 
the  thesis  team  sought  to  quantify  the  benefit  of  an  ISHMS  on  aging  aircraft.  In 
order  to  do  so,  the  thesis  team  had  to  assume  some  system  design  details  and  created 
simplified  simulations  to  compare  the  status  quo  with  an  ISHMS  installed  aircraft. 

5.3  Benefit  Analysis  (Cost  &  Safety) 

In  the  background  research  on  structural  health  monitoring  performed  for  this 
thesis,  the  potential  benefit  of  a  structural  health  monitoring  system  was  not  truly 
addressed  nor  quantified.  Most  discussion  on  the  topic  assumed  the  potential  benefit. 
This  thesis  considered  it  important  to  attempt  to  quantify  or  show  the  potential 
benefit  from  both  the  cost  and  safety  perspective,  especially  for  an  ISHMS  on  aging 
aircraft  where  installation  of  the  ISHMS  may  be  difficult  and  costly.  To  demonstrate 
the  benefit  of  an  ISHMS  on  aging  aircraft,  two  simplified  mathematical  simulations 
were  created,  one  simulating  flying  an  aging  aircraft  without  an  ISHMS  (baseline) 
and  one  simulating  flying  with  an  ISHMS  (ISHMS).  In  order  to  define  the  structure 
monitored,  quantify  the  material  properties,  and  crack  growth  associated  with  that 
structure,  a  specific  aircraft  had  to  be  chosen  for  the  simulations  and  the  CAF  A-37 
was  selected. 

5.3.1  Simulation  Inputs.  The  simulations  created  were  greatly  simplified, 
however,  since  the  same  assumptions  were  made  for  both  the  baseline  and  ISHMS 
simulations,  basic  comparative  conclusions  could  be  made  between  the  two  simula¬ 
tions.  Both  simulations  simulated  a  single  edge  crack  beginning  at  some  specified 
length  growing  towards  a  critical  length  in  one  particular  FCL  on  the  A-37.  The 
FCL  selected  for  the  simulation  was  the  number  one  FCL  identified  by  the  point  of 
highest  stress  in  the  A-37  wing.  The  Walker  Fatigue  crack  growth  model  was  used  to 
simulate  crack  growth.  The  material  properties  input  into  the  model  were  the  aver¬ 
age  properties  for  the  A1  7075-T6  material  of  the  FCL.  The  modeled  input  stresses 
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were  generated  from  the  average  mission  profile  stresses  from  the  fighter  spectra  from 
MIL-A-8866.  The  initial  crack  length  used  was  calculated  from  5000  hour  growth 
of  the  largest  crack  size  undetectable  by  human  sight.  The  critical  crack  length  was 
calculated  from  the  highest  possible  stress  on  the  FCL  with  a  crack  length  that  would 
cause  residual  strength  below  the  peak  stress.  While  most  other  inputs  to  the  model 
were  averages,  the  critical  crack  length  modeled  the  worst  case.  The  probability  of 
detection  for  the  maintenance  inspections  was  assumed  to  be  97%.  Whereas  the 
probability  of  detection  for  the  ISHMS  was  assumed  to  be  99.9%.  The  probability  of 
detection  for  the  ISHMS  encompassed  both  the  system  reliability  and  accuracy. 

5.3.2  Final  Comments  on  Benefit  Analysis.  A  comparative  analysis  between 
the  two  simulations  run  with  the  inputs  described  in  the  section  previous  showed  that 
an  ISHMS  may  provide  benefit  over  the  current  status  quo  with  respect  to  an  improve¬ 
ment  in  safety,  lower  number  of  failures  per  million  flight  hours,  and  cost,  decreased 
total  number  of  inspections.  The  cost  benefit  only  considered  the  total  number  of 
inspections  performed  between  the  two  simulations  and  assumed  the  inspections  per¬ 
formed  in  the  two  simulations  were  identical.  Of  course,  even  given  these  assumptions, 
a  cost  benefit  would  only  be  realized  if  the  life-cycle  costs  of  the  ISHMS  were  less  than 
costs  savings  from  reduced  inspections  over  the  life  of  the  aging  aircraft.  The  sim¬ 
ulations  assumed  one  crack  growing  in  one  FCL.  In  reality,  an  ISHMS  will  need  to 
monitor  multiple  FCLs  with  potentially  multiple  cracks  in  each  FCL.  In  this  case,  the 
realized  benefits  would  most  likely  be  lower  than  the  benefits  demonstrated  with  the 
simulations.  Additionally,  the  probability  of  detection  for  the  ISHMS  may  be  lower 
than  that  assumed  in  the  simulation  given  a  suite  of  sensors  attempting  to  accurately 
detect  surface  and  subsurface  cracks  growing  in  multiple  directions.  This  lower  prob¬ 
ability  of  detection  would  lower  the  potential  safety  benefit.  The  true  benefit  will  only 
be  known  given  a  specific  implementation  of  an  ISHMS  on  a  specific  aging  aircraft 
fleet  for  a  specific  lifetime  in  flight  hours. 
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The  generic  system  definition  of  an  ISHMS  for  aging  aircraft  developed  with 
this  thesis  lays  the  groundwork  for  future  development  and  research  efforts  in  this 
field.  This  thesis  also  determined  that  an  ISHMS  for  aging  aircraft  will  likely  provide 
a  benefit  with  respect  to  cost  and  safety.  However,  much  more  work  needs  to  be  done 
with  respect  to  the  problem  of  ISHMS  and  applying  the  SE  process  for  developing 
the  right  ISHMS  for  aging  aircraft. 

5-4  Recommendations  for  Further  Research 

5-4-1  Continuation  of  SE  Process.  Due  to  multiple  constraints,  this  thesis 
scoped  the  SE  process  developed  to  not  include  physical  architectures  and  system  de¬ 
sign.  Future  SE  efforts  should  continue  the  process  developed  here  to  include  physical 
architectures  and  system  design.  After  the  process  is  continued,  technical  feasibility 
could  be  determined.  Questions  to  be  answered  could  include:  Does  the  technol¬ 
ogy  exist  to  realize  safety  and/or  cost  benefits?  How  many  FCLs  and/or  sensors  are 
necessary  for  system  design?  Is  installation  of  the  ISHMS  technically  feasible?  Can 
the  ISHMS  be  effectively  integrated  with  aircraft  systems  such  as  GPS  and  aircraft 
power? 

5-4-2  ISHMS  Concept.  This  thesis  assumed  that  the  ISHMS  would  monitor 
actual  structural  damage  of  the  aircraft  and  most  likely  alert  the  aircraft  crew  of  the 
impending  failures.  The  ISHMS  could  be  designed  to  monitor  aircraft  use  such  as 
loads,  stresses,  cycles,  and  flight  hours,  for  instance.  Inputting  these  monitored  in¬ 
puts  into  a  model,  tailored  inspection  criteria  could  be  developed  for  each  individual 
aircraft  tail  number.  This  method  would  require  accurate  models  that  would  first  rely 
on  simulation  models  that  would  be  continually  refined  as  historical  data  is  gained. 
The  models  would  estimate  probable  structural  damage  which  would  have  to  be  ver¬ 
ified  with  maintenance  inspections.  Current  efforts  in  structural  health  monitoring 
focus  on  monitoring  damage  as  was  done  in  this  thesis.  Research  needs  to  be  done 
to  determine  the  optimal  implementation  of  an  ISHMS.  Should  an  ISHMS  monitor 
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damage,  monitor  aircraft  use  and  predict  damage,  or  some  combination  of  monitoring 
damage  and  use  for  a  more  complete  picture  of  aircraft  structural  health? 

5-4-3  Cost  Benefit  of  ISHMS.  The  benefit  analysis  performed  in  this  thesis 
only  considered  reduced  number  of  inspections  and  it  assumed  all  inspections  were 
identical.  More  detailed  analysis  of  the  cost  benefit  of  an  ISHMS  could  be  performed 
considering  a  larger  suite  of  sensors  monitoring  multiple  FCLs  simultaneously.  The 
detailed  analysis  should  attempt  to  quantify  the  maintenance  cost  savings  realized  for 
an  ISHMS  that  achieves  the  same  flight  safety  as  the  baseline  configuration.  Detailed 
life-cycle  costs  estimates  would  need  to  be  calculated  to  compare  to  the  maintenance 
cost  savings  estimated  to  generate  a  true  cost  savings  over  the  life  of  the  ISHMS.  Since 
the  maintenance  cost  savings  will  depend  on  how  the  user  will  implement  maintenance 
changes  with  respect  to  the  system,  multiple  estimates  of  costs  savings  could  be 
calculated  with  respect  to  different  user  system  implementations. 

5-4-4  ISHMS  Impact  on  Maintenance.  Assuming  the  development  and  in¬ 
stallation  of  an  ISHMS  on  aging  aircraft  occurs  in  the  future,  research  efforts  should 
focus  on  the  potential  impacts  to  maintenance  schedules  and  operations.  Depend¬ 
ing  on  the  user’s  implementation,  the  ISHMS  may  significantly  reduce  or  eliminate 
time-based  scheduled  inspections  and  subsequently  move  towards  a  tailored  inspec¬ 
tion  schedule  for  individual  aircraft  tail  numbers.  What  impact  would  such  a  shift 
in  maintenance  philosophy  have  on  maintenance  manning  and  operations?  Will  an 
ISHMS  increase  the  number  of  unscheduled  maintenance  actions?  These  questions  are 
just  a  few  of  the  possible  questions  that  could  be  answered  by  a  detailed  investigation 
into  the  ISHMS  effects  on  aircraft  maintenance. 
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Appendix  A.  Matlab  Code 

This  appendix  contains  the  Matlab®  code  for  both  the  baseline  simulation  and  the 
ISHMS  simulation. 


A.l  Baseline  Code 

Listing  A.l:  Here  is  the  Matlab®  code  used  for  the  baseline  simulation. 

(appendixl /baseline. m) 

clear ; 
clc  ; 

Inspection_Counter  =0;  7.  .  .  . 

Tracks  number  of  inspections  occurring  during  all  trials 


c 

=  0 

.  13E-7 ; 

5  F 

=  1 

.1; 

n 

=  2 

.  791  ; 

m 

=  . 

65; 

Delta_sigma  =  20152; 

Stress.Ratio  =  0; 

10  new_length  =  0.0079; 

initial_length  =  0.02589371; 
crack.critical  =  0.4781; 

Total_Flight_Hours  =  0; 
trial.hours  =  0; 

15 

for  i  =  1  :  1:1000;  7. 

Number  of  trials 
Total_Failures  =  0; 
for  j  =1 : 13 ; 

Trial_Failure  =  0; 


20  crack_length  =  initial_length  ;  7« 

Initial  crack  length  of  0.008  inches 
Trial_Failure  =  0;  7« 

Changes  to  one  when  a  trial  failure  occurs 
t  =  0;  7. 

Initialize  flight  hour  counter  to  zero 
Inspection_Time=0;  7o 

Counter  tracking  time  between  inspections 
while  and  (Trial_Failure  ==  0  ,  t  <=  5000)  7« 

No  trial  failures  and  time  less  than  5000  flight  hours 
25  if  Inspe ct i on.Time  ==  300 

p  =  rand  (  1 )  ;  7. 

Rand  detection  probability 
if  p  >  .03  7. 

Check  to  see  if  crack  is  detected  (977»  are  .. 
detected) 

crack.length  =  new_length;  7« 


If  crack  detected,  resets  length  to  new 
length 
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else 


crack.length  =  crack.length ; 

end 

Inspection_Time=0;  ”/. 

Resets  inspection  time 

Inspection.Counter  =  Inspection_Counter  +  1;  °/« 

Increments  inspection  counter 

end 

crack_gr owth  =  (C  *  (( F* De It a_ s igma * ( pi ()* crack. length 
)  ~  .  5)  /  (  ( 1  -  St r ess  _Rat  io  )  ~  (  1  -n)  )  )  ~m)  ;  ‘/.Crack  Growth 
Equation 

crack_length  =  crack_length  +  ( cr ack_gr owth *  1 00)  ;  ... 

"/.  Crack  growth 

if  crack_length  >  crack,  critical 

Checks  to  see  if  crack  is  greater  than  critical  ... 
length 

Trial_Failure  =  1; 

Total.Failures  =  Total.Failures  +  1; 

end 

trial.hours  =  t; 

t  =  t  +  1  ;  1 

Increment  time 

Inspection.Time  =  Inspection.Time  +  1;  ”/. 

Increment  inspection  time 

end 

Total_Flight_Hours  =  Total_Flight_Hours  +  trial.hours; 

end 

Results(i)  =  [Total.Failures];  “/. 

Builds  array  with  failure  data  from  all  trials 

end 

Average  =  mean ( Result s ) 

Std.Dev  =  std(Results) 

Failures  =  sum(Results) 
max  =  max(Results) 

Inspection.Counter 

Failures.Mln.Hours  =  ( Failure s / Tot al _F1 ight .Hour s )* 1 000000 
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A. 2  ISHMS  Code 


Listing  A. 2:  Here  is  the  Matlab®  code  used  for  the  ISHMS  simulation. 
(appendixl/ISHMS.m) 


clear ; 
clc  ; 

Inspection_Counter  =  0;  7«  Tracks  number  of  inspections  occurring 

during  all  trials 
C  =  0 . 13E-7 ; 

5  F  =  1.1; 
n  =  2.791; 
m  =  . 65 ; 

Delta_sigma  =  20152; 

Stress.Ratio  =  0; 

10  new_length  =  0.0079; 

initial_length  =  0.02589371; 
crack.critical  =  0.4781; 

Total_Flight_Hours  =  0; 
trial.hours  =  0; 


20 


for  i = 1 : 1:1000;  7.  . 

Number  of  trials 
Total_Failures  =  0; 

for  j  =1 : 1 : 13 ;  1  ... 

Number  of  Aircraft  in  fleet 
crack_length  =  initial_length  ;  ... 

'/.  Initialize  crack  length 

Trial_Failure  =  0;  ... 

7,  Changes  to 

one  when  a  trial  failure  occurs 


25 


30 


t  =  0 ;  ... 

% 

Initialize  flight  hour  counter  to  zero 
Inspe ct i on.Time  =  0;  ... 

‘/,  Counter  .  .  . 


tracking  time  between  inspections 
while  and (Trial_Failure  ==  0,  t  <=  5000)  ... 

%  No  trial  failures  and  time  less  . 
than  5000  flight  hours 

ifInspection_Time==700  7. 

Sets  inspection  timeframe 
p  =  rand ( 1 ) ; 
if  p  >  .03  ... 

7.  ... 

Random  number  draw  to  see  if  crack  is  detected 
(97  7«  detected) 
crack_length  =  new_length; 

end 

Inspe ct i on.Time  =  0; 

Inspection.Counter  =  Inspection_Counter  +  1; 

end 
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cr ack_gr owth  =  (C  *  ( ( F*Delta_sigma* (pi () * crack_length .  .  . 
)  ~  .  5) / ( ( 1  -  St r es s_Rat io ) ~ ( 1 -n) ) ) ~m)  ;  %  Crack  ... 

growth  equation 

crack_length  =  crack_length  +  ( cr ack_gr owth *  1 00)  ;  ... 

%  Crack  growth  equation  cont . 
if  crack_length  >  . 9* crack.critical  ... 

•/„  ISHMS  checks  to  see  if  ... 
crack  is  greater  than  90%  of  critical 
pi  =  rand ( 1 ) ; 
if  pi  >  .999 

Trial_Failure  =  1; 

Total.Failures  =  Total_Failures  +  1; 

else 

crack_length  =  new_length; 

Inspection.Time  =  0; 

Inspection_Counter  =  Inspection.Counter  +  1; 

end 

end 

trial_hours  =  t; 
t  =  t  +  1  ; 

Inspection_Time  =  Inspe ct i on.Time  +  1; 

end 

Total_Flight_Hours  =  Total_Flight_Hours  +  trial.hours ; 

end 

Results(i)  =  [Total_Failures ] ; 

end 

Average  =  mean ( Result s ) 

Std_Dev  =  std(Results) 

Failures  =  sum(Results) 

Inspect ion_ Counter 

Failures_Mln_Hours  =  ( Fai lure s / Tot al _F1 ight .Hours )* 1 E6 
Max.Failures  =  max(Results) 
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Appendix  B.  Integrated  Data  Dictionary  (AV-2) 


Functional  Activities  Listed  in  Alphabetical  Order 

Determine  Aircraft  Inspection  Intervals  -  an  ISHMS  may  be  able  to 
reduce  the  inspection  burden,  but  not  eliminate  the  need  for  some 
inspections.  As  such,  one  of  the  potential  benefits  of  an  ISHMS 
come  from  cost  avoidance  of  inspection  and  maintenance  costs. 

Determine  Aircraft  Structural  Condition  -  once  an 
aircrafts  ISHMS  data  has  been  collected  and  analyzed, 
then  the  aircraft's  structural  condition  should  be 
determined . 

Determine  Available  Sensor  Technology  -  sensor 
selection  for  each  FCL  will  be  limited  by  the  technology 
that  is  available  in  the  market;  either  existing  or  emerging 
technology . 

Determine  Data  Analysis  Requirements  -  define  the 
purposes  of  the  data,  the  methodology  for  any 
calculations  required,  organizations  responsible  for 
conducting,  verifying,  and  validating  the  analysis,  etc. 

Determine  Data  Processing  Requirements  -  manipulating 
the  ISHMS  sensor  data  such  that  it  would  be  suitable  to 
conduct  the  appropriate  analysis. 
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Determine  Data  Requirements  -  design  aspects  relating 
to  data  format,  data  storage,  data  filtering,  etc. 

Determine  Data  Storage  Requirements  -  data  from  the 
sensors  must  be  stored  somewhere.  Several  data 
characteristics  will  determine  the  storage  requirements 
needed  for  the  ISHMS. 

Determine  Desired  ISHMS  Accuracy  -  this  refers  to  the 
desired  level  of  confidence  of  the  ISHMS  in  detecting 
failures  on  structural  members. 

Determine  Failure  Mode  to  be  Detected  -  each  sensor 

must  be  tailored  to  the  specific  fatigue  location  that  it  will 

be  monitoring. 

Determine  ISHMS  Calibration  Requirements  -  validation 
and  verification  of  the  ISHMS. 

Determine  ISHMS  Maintenance  Requirements  -  details 
about  system  sustainment,  calibration,  maintenance  and 
the  respective  organizations  or  systems  responsible  of 
providing  the  maintenance  services. 

Determine  ISHMS  Operational  Requirements  -  this  is  the 
activity  in  which  stakeholders  express  their  expectations 
of  how  the  ISHMS  should  operate  and  what  services  it 
should  provide.  More  detailed  information  will  most  likely 
translate  into  a  more  satisfied  customer. 
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Determine  ISHMS  Reliability  -  calculations  made  to 
determine  the  expected  operational  availability  of  the 
system.  Redundant  systems  are  usually  more  reliable, 
but  also  more  complex  and  costly. 

Determine  ISHMS  Routine  and  Preventive  Maintenance 
Procedures  -  procedures  for  the  sustainment  and 
maintenance  of  the  ISHMS.  Includes  repairing  the 
ISHMS  and  keeping  it  fully  operational. 

Determine  Monitoring  Requirements  -  design  aspects 
relating  to  the  placement,  quantity,  and  sensor  type 
selection.  These  characteristics  will  define  to  a  great 
extent  the  physical  systems  necessary  to  build  an  ISHMS 
that  would  satisfy  stakeholders. 

Determine  Operating  Environment  -  environmental 
factors,  both  internal  and  external,  may  influence  the 
sensor  selection  for  each  critical  location.  Examples  of 
environmental  factors  are  humidity,  vibration, 
temperature,  etc. 

Determine  Safety  of  Flight  -  SOF  is  measured  in 
statistical  terms.  The  ISHMS  should  be  able  to  at  least 
maintain  the  level  of  SOF  that  is  currently  attained  with 
the  inspections.  It  would  probably  take  into  consideration 
several  factors  to  include  the  reliability  of  the  ISHMS. 
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Determine  Sensor  Locations  -  establishing  the  placement 
of  the  sensors  will  be  a  critical  design  feature  of  the 
ISHMS. 


Determine  Sensor  Properties  Requirements  -  each 
individual  sensor  must  be  tailored  to  the  specific  fatigue 
critical  location  that  it  will  be  monitoring.  Sensor  types 
may  differ  due  to  differences  in  failure  modes,  loading 
stresses,  environmental  factors  among  other  issues  that 
may  vary  among  fatigue  critical  locations.  Response 
time  must  also  be  considered  as  a  potential  driving 
requirement  to  satisfy  the  near-real  time  user 
requirement . 

Determine  Sensor  Quantity  -  answers  how  many  sensros 
will  be  needed.  Obviously  this  activity  involves  trade-offs 
between  costs  and  robustness  of  the  system.  Ideally, 
more  sensors  will  do  a  better  monitoring  job;  however  an 
increasing  number  of  sensors  will  increase  the  cost  and 
complexity  of  the  ISHMS. 

Determine  Sensor  Selection  -  the  activity  of  matching  a 
specific  sensor  to  an  FCL. 

Identify  Fatigue  Critical  Locations  -  weakened  areas  in 
an  aircraft’s  structural  members  whose  failure  can  lead  to 
a  catastrophic  event.  Usually,  historical  failure  trends 
could  be  used  to  identify  some  FCLs  on  an  airframe. 
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Identify  ISHMS  Requirements  -  This  is  the  context 
diagram  for  the  ISHMS  architectures  and  defines  the 
boundaries  of  the  subsequent  decompositions.  Notice 
the  purpose  of  the  architectures  is  to  establish  a 
systematic  approach  to  generate  or  identify  stakeholder 
requirements.  Engineers  shall  incorporate  these 
requirements  into  the  system  design  to  ensure 
stakeholder  satisfaction  when  the  final  ISHMS  solution  is 
delivered. 

Identify  Other  Critical  Locations  -  do  not  limit  the 
research  of  catastrophic  failure  to  only  FCLs.  Include  in 
the  analysis  other  components  that  may  be  beneficial  to 
monitor  with  the  ISHMS. 

Make  Informed  Fleet-wide  Decisions  -  this  refers  to  the 
thesis  scenario  in  which  commanders  may  be  able  to 
switch  aircraft  tail  numbers  in  order  to  maintain  an  even 
wear  and  tear  among  aircrafts  organization-wide 
according  to  ISHMS  information. 

Prioritize  Critical  Locations  -  a  risk  management  analysis 
would  probably  be  most  suitable  in  accomplishing  this 
activity.  Monitoring  Emphasis  should  be  placed  on  thos 
FCLs  that  have  a  higher  risk  of  catastrophic  failure. 

Provide  Necessary  Aircraft  Maintenance  -  plan  follow-on 
repair/maintenance  procedures  based  on  the  ISHMS 
assessment  and  any  additional  inspections.  In  other 
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words,  an  ISHMS  may  help  in  the  planning  and 
scheduling  of  aircraft  maintenance  operations. 


ICOMs  Listed  in  Alphabetical  Order 

Aircraft  Design  Characteristics  -  design  features  that  make  an 
aircraft  design  unique  or  different.  Can  also  be  thought  of  as  an 
aircraft  implementation.  Includes  criteria  such  as  weight  and 
balance  limits,  electronic-  magnetic  interference  (EMI) 
constraints,  aircraft  power  limits,  etc. 

Aircraft  Inspection  Intervals  -  the  amount  of  time  (often 
measured  in  flight  hours)  between  required  aircraft 
inspections.  These  inspections  are  often  required  as 
part  of  the  ASIP  and  SLEP,  or  any  other  program 

designed  to  extend  the  life  of  an  aircraft  beyond  the  original  design  life. 

Aircraft  Maintainers  -  flightline  personnel  dedicated  to  repairing 
or  reconditioning  aircraft  to  an  operational  status. 

Aircraft  Maintenance  Report  -  report  generated  to  log  the 
maintenance  performed  on  an  aircraft.  This  data  may  be 
used  to  identify  new  FCLs. 

Aircraft  Structural  Health  Condition  -  the  resulting 
assessment  from  the  ISHMS  data  analysis  combined 
with  any  other  inspections  performed. 
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Analyzed  Data  -  the  results  or  outcomes  of  the  ISHMS 
data  analysis. 

Bandwidth  Availability  -  the  amount  of  ISHMS  sensorial 
data  that  can  be  passed  along  a  communications 
channel  in  a  given  period  of  time. 

Assessment  of  the  damage  the  aircraft  specimen 
currently  has  prior  to  test. 

Calibrated  Instrument  -  verification  and  validation  that  the 
ISHMS  is  making  accurate  measurements. 

Cost  /  Budget  -  the  total  sum  of  money  allocated  for  a 
particular  purpose  or  period  of  time. 

Critical  Locations  Priority  List  -  a  list  of  critical  locations  in 
order  of  importance .  The  order  of  importance  will  most 
likely  be  determined  by  factors  such  as  frequency  of 
occurrence  and  potential  for  damage  (Risk 
Management) . 

Current  Fleet  Status  Report  -  one  of  the  outputs  that  the 
ISHMS  would  be  expected  to  generate.  An  ISHMS  could 
potentially  allow  commanders  assess  their  unit's 
readiness  with  the  click  of  a  button. 

Data  Acquisition  Unit  -  a  hypothetical  component  that  will 
store  sensor  data.  This  mechanism  can  be  performed  by 
an  automated  system  or  by  some  human  organization,  or 
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a  combination  of  both. 


Data  Format  -  the  computer  language  and  structure  in 
which  the  data  must  be  written.  This  may  be  important  in 
preventing  software  compatibility  issues,  especially  if  the 
ISHMS  needs  to  interact  with  legacy  systems. 

Data  from  Sensors  -  raw  signal  inputs  coming  from  each 
ISHMS  sensor. 

Engineering  Analysis  -  scientific  studies  performed  to 
determine  ISHMS  design  characteristics. 

Engineers  -  are  a  subset  of  stakeholders.  May  be  either 
contractors,  military  or  government  civilian.  Probably 
composed  of  a  multi-disciplinary  mixture  of  mechanical, 
aeronautical,  electrical,  computer  and  system  engineers. 
Perhaps  some  scientists  may  also  be  included  in  this 
category  (i.e.,  experts  in  ceramics,  computer  networks, 
maintainers,  etc.) 

Environmental  Factors  -  a  combination  of  surrounding 
conditions  that  may  affect  the  state  of  the  systems  that 
compose  the  ISHMS.  Environmental  factors  can  be 
either  internal  or  external.  Internal  factors  refer  to  the 
localized  environmental  factors  within  the  airframe 
structure.  For  example,  a  fatigue  critical  location  that 
needs  to  be  monitored  may  be  submerged  in  hydraulic 
fluid,  or  may  experience  a  high  vibration  frequency  and 
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temperature  due  to  its  proximity  to  the  engine,  etc. 
External  factors  refer  to  the  operational  environment 
area.  For  example,  proximity  to  sea  water  may  promote 
corrosion  problems,  a  dusty  environment  may  require  a 
more  robust  sensor,  extremely  cold  temperatures  may 
affect  the  electronic  properties  of  the  sensor,  etc. 
Failure  Mode  -  the  most  probable  failure  mode  or  modes 
that  the  FCL  may  experience  (i.e.,  corrosion,  shear  or 
load  stress,  vibration,  etc.) 

Fatigue  Critical  Locations  -  areas  where  structural 
members  are  more  vulnerable  to  damage  that  can  lead 
to  catastrophic  failure.  Each  FCL  may  have  one  or 
multiple  failure  modes.  Failure  may  be  due  to  crack 
growth,  corrosion,  fatigue  stress,  load  stress,  etc. 

Flight  Profile  -  refers  to  the  severity  or  level  of 
aggresiveness  with  wich  the  aircraft  is  being  flown. 
Usually  this  will  depend  on  the  aircraft's  role  or 
operational  mission. 

Historical  Data  -  information  based  on  a  record  of 
previous  events .  In  the  case  of  the  development  of  an 
ISHMS  this  may  include  maintenance  records,  accident 
reports  and  any  other  aircraft  information  that  has  been 
logged  through  time.  Emphasis  should  be  placed  on 
identifying  trends  of  repetitive  safety  issues. 

ISHMS  Design  Requirements  -  a  compilation  of  all 
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stakeholders'  requirements.  This  will  help  constraint  the 
design  space  (i.e.,  the  number  of  acceptable  ISHMS 
solutions),  thus  simplifying  the  development  phase. 

List  of  Sensors  Available  -  the  list  would  show  the  range 
of  sensor  that  have  the  potential  of  being  part  of  an 
ISHMS. 


Maintenance  Practices  -  the  rigor  or  lack  of  efficient 
maintenance  practices  will  most  likely  have  an  impact  of 
the  number  and  priority  of  potential  structural  problematic 
areas . 

Maintenance  Procedures  -  should  be  included  early  on 
the  design  phase  as  part  of  the  lifecycle  design 
requirements.  Inevitably,  some  components  of  the 
ISHMS  will  fail  and  will  have  to  be  replaced. 

Consideration  of  maintenance  procedures  will  prevent 
the  creation  of  a  remedy  (i.e.,  ISHMS)  that  is  worst  than 
the  cause  (i.e.,  inspections). 

Operating  Environment  -  external  and  internal 
environmental  factors  that  affect  sensor  selection 

Operational  Aircraft  -  an  aircraft  100%  ready  for 
operational  use. 

Other  Critical  Locations  -  these  are  non-FCL  locations 
that  historically  have  experienced  high  failure  rates  and 
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have  the  potential  to  capitalize  on  the  implementation  of 
an  ISHMS. 


Other  Inspections  -  inspections  required  to  have  a 
complete  assessment  of  an  aircraft’s  condition.  Other 
inspections  may  be  prompted  as  a  result  of  ISHMS  data 
analysis  or  may  be  required  because  of  ISHMS 
deficiencies . 

Policies  &  Regulations  -  established  principles,  rules,  or 
laws  designed  to  control  or  govern  conducts  or 
procedures . 

Probability  of  Detection  -  the  ability  of  the  ISHMS  to 
detect  a  failure  only  when  there  is  actually  a  potential 
failure  or  not  detecting  failure  when  there  is  none.  This 
relates  to  the  probability  concept  of  confidence  level 
(false-false  and  false-true) . 

Processed  Data  -  raw  data  that  has  been  converted. 

Examples  are  time  stamping  the  data  for  synchornization 
purposes,  sorting  data,  filtering  the  data,  etc. 

Research  Practices  -  the  skills,  knowledge  and 
professionalism  of  whoever  is  conducting  a  scientific 
research  or  analysis  may  have  an  impact  on  the  final 
outcome . 


Safety  of  Flight  -  the  level  of  safety  expected  that  the  ISHMS 
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must  sustain  for  aircraft  operation.  Most  likely  will  be 
established  by  the  user  and  is  usually  measured  in  statistical  or 
probabilistic  terms. 

Sensor  Quantity  -  the  number  of  sensors  that  the  ISHMS 
will  require  to  satisfy  stakeholder’s  needs. 

Sensor  Selection  -  a  match  of  a  sensor  tailored  to  the 
FCL  it  will  monitor. 

Stakeholders  -  anyone  who  has  a  share  or  an  interest  in 
the  ISHMS.  Usually  includes  developers,  designers, 
users,  contractors,  etc. 

Stakeholder’s  Inputs  -  preferences  established  by  the 
stakeholders .  Extreme  care  must  be  taken  to  properly 
justify  all  stakeholders’  inputs.  The  ISHMS  design  must 
not  be  influenced  by  an  individual’s  will  nor  by  group 
think. 

Stored  Data  -  data  that  has  been  stored  in  the  data 
acquisition  unit. 

Technology  -  defined  as  the  practical  application  of  science  to 
commercial  or  industrial  purposes.  Technology  can  be  classified 
into  emerging  or  existing.  Existing  technology  is  usually  more 
readily  available  and  cheaper.  Existing  technology  usually  needs 
to  be  validated  before  integrating  it  into  a  design. 
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Upper  Management  -  a  subset  of  the  stakeholders  that 
have  an  authority  beyond  normal.  These  people  may 
have  the  influence  to  implement  major  decisions  that 
have  the  potential  to  effect  changes  on  other  systems  or 
organizations . 
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Appendix  C.  Performance  Indices 


This  appendix  contains  the  Performance  Indices  for  the  requirements  Weighted 
Objectives  Hierarchy.  First,  the  cost  indices  are  presented,  followed  by  the  perfor¬ 
mance  indices  and  finally  the  schedule  index. 


Figure  C.l:  Development  Cost  Performance  Index 
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Performance  Weight 


Figure  C.2:  Acquisition  Cost  Performance  Index 


Figure  C.3:  Installation  Cost  Performance  Index 
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Performance  Weight 


Figure  C.4:  Operation  Cost  Performance  Index 


Figure  C.5:  Disposal  Cost  Performance  Index 
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Performance  Weight 


Figure  C.6:  Probability  Of  Detection  Performance  Index 


Figure  C.7:  Crack  Length  Detection  Performance  Index 
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Performance  Weight 


Figure  C.8:  Sampling  Rate  Performance  Index 


Figure  C.9:  Data  Storage  Performance  Index 
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Figure  C.10:  System  Reliability  Performance  Index 


Figure  C.ll:  Low  Operating  Temperature  Performance  Index 
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Figure  C.12:  High  Operating  Temperature  Performance  Index 


Performance  Weight 


Figure  C.13:  Mean  Time  Between  Failure  Performance  Index 
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Performance  Weight 


Figure  C.14:  24  Hour  Fix  Rate  Performance  Index 


Performance  Weight 


Figure  C.15:  Calibration  Interval  Performance  Index 
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Figure  C.16:  Analysis  Ease  of  Use  Performance  Index 
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Figure  C.17:  Pilot  Cuing  Performance  Index 
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Figure  C.18:  Schedule  Performance  Index 
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